force esm via tsconfig, remove package.json creation

[josefaidt]

Problem

The purpose of the existing amplify/package.json file is to force the backend project to be an ESM project, and treat all backend project files as ES modules. The existence of this file and the one created at the project root (i.e. above amplify/) can be confusing as it is often used to define dependencies. There have been a few reports of the confusing experience as modules will resolve as they are installed during sandbox, but are not resolved during branch builds using the default configuration, and customer branch deployments fail.

This change is largely from the guidance from the official tsx docs's recommendation

{
	"compilerOptions": {

		// Treat files as modules even if it doesn't use import/export
		"moduleDetection": "force",

		// Ignore module structure
		"module": "Preserve",

		// Allow JSON modules to be imported
		"resolveJsonModule": true,

		// Allow JS files to be imported from TS and vice versa
		"allowJs": true,

		// Use correct ESM import behavior
		"esModuleInterop": true,

		// Disallow features that require cross-file awareness
		"isolatedModules": true,
	},
}

This change:

• changes module from es2022 to preserve
• removes moduleResolution
• adds moduleDetection with force
• removes package.json creation

Existing customers will not be impacted, and no changes are required on their part, however later it will be noticed that create-amplify no longer creates the same files or configuration.

Moving forward, would it benefit us from creating the tsconfig.json inside .amplify/ (creating this file preemptively), and extend-ing it from the customer's amplify/ directory? This would allow us to make further changes to this file and create on demand since it is gitignored.

Issue number, if available:

Changes

Corresponding docs PR, if applicable:

Validation

I created a sample project and modified it in place,
josefaidt/repro-amplify-gen2-moduledetection@076d870

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: e0768bb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
create-amplify	Patch
@aws-amplify/cli-core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[sobolk]

Can you run e2e tests on this PR?
And make sure all checks are passing?

[sobolk]

Few things here.

1. TS docs mention esnext next to preserve: You very likely want "nodenext" for modern Node.js projects and preserve or esnext for code that will be bundled . Why would we choose preserve over esnext ? (unless bundling doesn't matter here anymore).
2. preserve was added in Typescript 5.4 . If we do this we have to bump Typescript to ^5.4.0. Including here

   amplify-backend/packages/create-amplify/src/amplify_project_creator.ts

   Line 21 in 7bf0c64

   'typescript@^5.0.0',

[josefaidt]

for 1, bundling doesn't matter here aside from Functions. nodenext is the one that'll force you to specify .js file extensions (though I think there's a new compiler option coming that'll support .ts extensions and transform). preserve will not transform your module syntax, which should yield the same results when writing with ESM syntax using import/export instead of require/module.exports

for 2, bumped the minimum version