Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow imports with .js extension #4591

Closed
cyrilletuzi opened this issue Feb 10, 2017 · 5 comments
Closed

Allow imports with .js extension #4591

cyrilletuzi opened this issue Feb 10, 2017 · 5 comments
Assignees
Labels
P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful

Comments

@cyrilletuzi
Copy link
Contributor

Versions.

@ngtools/webpack 1.2.9

Repro steps.

Since TS 2.0, it's possible to :
import { Something } from './something.js';

Module identifiers allow for .js extension

Before TypeScript 2.0, a module identifier was always assumed to be extension-less; for instance, given an import as import d from "./moduleA.js", the compiler looked up the definition of "moduleA.js" in ./moduleA.js.ts or ./moduleA.js.d.ts. This made it hard to use bundling/loading tools like SystemJS that expect URI's in their module identifier.

With TypeScript 2.0, the compiler will look up definition of "moduleA.js" in ./moduleA.ts or ./moduleA.d.ts.

But using this possibility with @ngtools/webpack results in error :
Module not found: Error: Can't resolve './something.js'

It's important to be compatible with ES6 modules, which require the .js extension, as <script type="module"></script> is now in test in all browsers, and as for now TS doesn't provide an option to add the .js extension in transpiled files (see microsoft/TypeScript#13422).

It's possible when using ngc directly, and also in rollup/rollup-plugin-typescript so I assume it's possible with @ngtools/webpack too.

@filipesilva filipesilva added the P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful label Mar 9, 2017
@hansl hansl added this to the 1.0 Final Blocking milestone Mar 16, 2017
@hansl hansl assigned Brocco and unassigned hansl Mar 16, 2017
@Brocco
Copy link
Contributor

Brocco commented Mar 17, 2017

I was able to get this to work locally without any changes to the CLI itself.

In your generated project's tsconfig.json under compilerOptions you will need to add "allowJs": true. This will allow tsc to resolve the references to .js files.

VS Code provided the related warning to discover this flag:
image

@Brocco Brocco closed this as completed Mar 17, 2017
@cyrilletuzi
Copy link
Contributor Author

Do we agree the original file is tester.ts ?

It's not about including .js files, it's about loading .ts files (as Angular is in TypeScript) but accordingly to the ES modules loading spec.

@Brocco
Copy link
Contributor

Brocco commented Mar 17, 2017

I see what you're saying now, I am looking through this now.

@Brocco Brocco reopened this Mar 17, 2017
@hansl
Copy link
Contributor

hansl commented Mar 21, 2017

Unfortunately, I'm going to close this as Working As Intended right now.

The ESM spec is not finalized yet, and webpack does not support it. We found no problem in the CLI code, but we end up passing require() calls pointing to those .js files to webpack, and webpack itself fails to resolve them.

We will continue investigate this as ESM is finalized and webpack support is added. We may release a minor update to support it at that time. Cheers.

@hansl hansl closed this as completed Mar 21, 2017
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful
Projects
None yet
Development

No branches or pull requests

4 participants