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

Provide a way to add the '.js' file extension to the end of module specifiers #16577

Closed
quantuminformation opened this issue Jun 16, 2017 · 286 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision Domain: ES Modules The issue relates to import/export style module behavior Suggestion An idea for TypeScript

Comments

@quantuminformation
Copy link

quantuminformation commented Jun 16, 2017

In order to use es6 modules in the browser, you need a .js file extension. However output doesn't add it.

In ts:
import { ModalBackground } from './ModalBackground';
In ES2015 output:
import { ModalBackground } from './ModalBackground';

Ideally I would like this to be output
import { ModalBackground } from './ModalBackground.js';

That way I can use the output in Chrome 51

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Webpack boilerplate</title>
  <script type="module" src="index.js"></script>
</head>
<body></body>
</html>

image

Related to #13422

@cyrilletuzi
Copy link

It's not just related to #13422, it's the same issue. But responses have been quite negatives, despite the fact I think it's a important issue, so hope your issue will be better received.

@quantuminformation
Copy link
Author

quantuminformation commented Jun 16, 2017

Well, I hope its added, we were really looking forward to discussing my POC using this in my next TypeScript podcast, but looks like we will have to wait to use TypeScript with no build tools.

@DanielRosenwasser
Copy link
Member

At the moment TypeScript doesn't rewrite paths. It's definitely annoying, but you can currently add the .js extension yourself.

@DanielRosenwasser DanielRosenwasser added the Suggestion An idea for TypeScript label Jun 17, 2017
@DanielRosenwasser DanielRosenwasser changed the title Add .js file extensions to import declarations output for use in Chrome 51 ES6 module imports Provide a way to add the '.js' file extension to the end of module specifiers Jun 17, 2017
@DanielRosenwasser DanielRosenwasser added the Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. label Jun 17, 2017
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 17, 2017

@justinfagnani @rictic

@quantuminformation
Copy link
Author

Thanks for the tip, I'll write a shell/node script to do this.

@justinfagnani
Copy link

@DanielRosenwasser would it make sense to collect the native ES6 module issues under a label?

@justinfagnani
Copy link

Also, to generalize this issue a bit, I don't think it's actually about adding a .js extension, but resolving the module specifier to an actual path, whatever the extension is.

@DanielRosenwasser DanielRosenwasser added the Domain: ES Modules The issue relates to import/export style module behavior label Jun 18, 2017
@quantuminformation
Copy link
Author

quantuminformation commented Jun 19, 2017

I've come across another issue which isn't really the domain of typescript but it's for my use case.

I'm not sure how to handle node_modules. Normally webpack bundles them into the code via the ts-loader but obviously, this is not understood by the browser:

import { KeyCodes } from 'vanilla-typescript;
https://github.com/quantumjs/vanilla-typescript/blob/master/events/KeyCodes.ts#L3

Adding a js extension here is meaningless.

I guess there would have to be a path expansion by typescript or a url resolver running on the server.

I appreciate its a rather niche case, but I think it would be a way TS could shine early in this area. Maybe it could be a plugin to the tsc compiler?

@quantuminformation
Copy link
Author

quantuminformation commented Jun 22, 2017

For anyone coming to this and wants an interim solution I wrote a script to add a js file extension to import statements:

"use strict";

const FileHound = require('filehound');
const fs = require('fs');
const path = require('path');

const files = FileHound.create()
  .paths(__dirname + '/browserLoading')
  .discard('node_modules')
  .ext('js')
  .find();


files.then((filePaths) => {

  filePaths.forEach((filepath) => {
    fs.readFile(filepath, 'utf8', (err, data) => {


      if (!data.match(/import .* from/g)) {
        return
      }
      let newData = data.replace(/(import .* from\s+['"])(.*)(?=['"])/g, '$1$2.js')
      if (err) throw err;

      console.log(`writing to ${filepath}`)
      fs.writeFile(filepath, newData, function (err) {
        if (err) {
          throw err;
        }
        console.log('complete');
      });
    })

  })
});

I might make this into a cli tool..

@aluanhaddad
Copy link
Contributor

@justinfagnani's comment hits the nail on the head.

Also, to generalize this issue a bit, I don't think it's actually about adding a .js extension, but resolving the module specifier to an actual path, whatever the extension is.

when you write

import { KeyCodes } from 'vanilla-typescript';

or for that matter

import { KeyCodes } from 'vanilla-javascript';

you are importing from an module specifier, it may or may not be a file but adding .js to the end in this case is not likely to result in a valid resolution.

If you are writing a NodeJS application then the NodeJS Require algorithm will attempt various resolutions but it will likely not attempt to resolve it to 'vanilla-typescript.js' because it references an abstract name and will, by convention and by configuration, be resolved (perhaps over various attempts) to something like '../../../node_modules/vanilla_typescript/index.js'.

Other environments, such as AMD have differences as to how they perform this resolution but one thing that all of these environments have in common is some notion of an abstracted module specifier.

I bring this up because the ES Module implementations shipping in various browsers implement something that is incomplete. If we consider even our simplest dependencies, and as soon as we broach the subject of transitive ones, it becomes clear that there will need to be a way to configure the doggone thing.

That may be far off, but as you are discovering, it is not realistic to write to this (politely) proof of concept implementation we have been given.

Furthermore, I do not see how TypeScript could possibly help here since the issue is environment specific.

@quantuminformation your program for adding .js to paths looks nice, lightweight, elegant even, but you are ultimately implementing your own module bundler. That is fun and interesting work but it demonstrates the deficiencies in the current implementations available in browsers. Even if you write in pure JavaScript, you still need something to compile and package your transitively imported dependencies.

I am basically just ranting about the fact that the implementation of ES Modules that was released is tremendously far from adequate.

Again NodeJS, RequireJS AMD, Dojo AMD, Sea Package Manager, CommonJS, Browserify, Webpack, SystemJS, all have their own differing ways of doing things but they all provide abstract name resolution. They have to provide it because it is fundamental.

Thank you for reading my rant.

@AviVahl
Copy link

AviVahl commented Nov 10, 2017

Not sure which version of TS added it, but imports such as './file.js' now work (even if the file is actually file.ts).
TypeScript resolves the file fine, and outputs the complete .js import to the target.
lit-html use it: https://github.com/PolymerLabs/lit-html/blob/master/src/lib/repeat.ts#L15

@cyrilletuzi
Copy link

It's possible since TS 2.0. But tools like webpack don't support it so in the end it's useless.

@AviVahl
Copy link

AviVahl commented Nov 11, 2017

It's useless if one is using ts-loader on sources (the most common use-case).
It is still possible to bundle the target (usually "dist" folder), as the actual js file exists there and can be found by the resolution process.

I wonder if I could implement a quick transformation in ts-loader that strips .js extensions from the target code, allowing one to bundle directly from sources.

@cyrilletuzi
Copy link

Feel free to do so, that would be great. I posted the issue on main webpack ts loaders, like ts-loader, a few months ago, and I've been quite badly received...

For information, there is no problem with the rollup typescript plugin, as a proof it's doable.

@aluanhaddad
Copy link
Contributor

I fail to see what good this does until browser loader implementations and the WGATWG loader spec support at least some configuration because most dependencies won't load correctly.

From my point of view, none of this matters until it is practical to use the native loader on an import that refers to an arbitrary string literal specifier, something that may not yet be a URL, and have that go through a transformation that yields the actual URL.

Until then we will remain dependent on tools like SystemJS and Webpack.

@AviVahl
Copy link

AviVahl commented Nov 11, 2017

I created a tiny transformer that strips the '.js' from import/export statements.
I used tsutils type guards, so yarn add tsutils --dev. (the package is usually installed anyway if you have tslint in your project, so so extra dependency)

https://gist.github.com/AviVahl/40e031bd72c7264890f349020d04130a

Using this, one can bundle ts files that contain imports from files that end with .js (using webpack and ts-loader), and still transpile sources to esm modules that can load in the browser (using tsc).

There is probably a limited number of use-cases where this is useful.

EDIT: I updated the gist to work with exports as well. it's naive and not optimized, but works.

@quantuminformation
Copy link
Author

Any movement on this issue?

@SalathielGenese
Copy link

This matter of extension take us back to the very begining of TypeScript and why a tsconfig.json was needed and why a module option was added to the compilerOptions setting.

Since that matter of extension of extension matters only for ES2015+ as require is able to resolve quite well, let it be added by the compiler when targeted code is ES2015+.

  1. .js for .ts
  2. .jsx for .tsx

@matthewp
Copy link

Hello, I'm coming at this late but would like to help. I am having trouble understanding what the issue is here. From the OP example it is:

import { ModalBackground } from './ModalBackground';

Is the issue that we don't know what './ModalBackground' is? It could be a folder or something else?

If we run tsc on the entire project and we know that ModalBackground.ts exists, then we would know that it is safe to add the extension, no?

@benlesh
Copy link

benlesh commented Jan 12, 2018

This issue is also something the RxJS community is very interested in. What is the timeline on a solution for this? Is it even prioritized? Are there any third party transformations that would help?

@TheLarkInn
Copy link
Member

I'm not really sure if this is a problem if the output target is ES2015 is it? This could maybe fall into the domain of a ES2015browser capability. Even more so, @justinfagnani can't we push for this as a platform goal to worry about? (Maybe need to fork into separate thread).

syvb added a commit to syvb/svelte-loader that referenced this issue Oct 28, 2020
In Webpack 5+, this is required to load Svelte correctly, due to what appears to be code generation issues with TypeScript:

microsoft/TypeScript#16577

This works around that by using telling end users to use a newly added feature in Webpack 5+, that uses Webpack 4 behavior for resolving module names:

https://webpack.js.org/configuration/module/#resolvefullyspecified
syvb added a commit to syvb/svelte-loader that referenced this issue Oct 28, 2020
In Webpack 5+, this is required to load Svelte correctly, due to what appears to be code generation issues with TypeScript:

microsoft/TypeScript#16577

This works around that by using telling end users to use a newly added feature in Webpack 5+, that uses Webpack 4 behavior for resolving module names:

https://webpack.js.org/configuration/module/#resolvefullyspecified
FarazzShaikh added a commit to FarazzShaikh/WebAssemblr that referenced this issue Jan 4, 2021
@FunctionPoint
Copy link

FunctionPoint commented Jan 4, 2021

Jeez, this is super annoying.
TypeScript transpiles to JS but then generates broken (modern) JS code.
Just add the option already to generate the ".js" extension for imports in transpiled JS
and make 1000's of developers happy...

@pauldraper
Copy link

pauldraper commented Jan 4, 2021

TypeScript transpiles to JS but then generates broken (modern) JS code.

?

It works fine

example.ts

import { Example } from './example.js';

compiles to

example.js

import { Example } from './example.js';

@FunctionPoint
Copy link

FunctionPoint commented Jan 4, 2021

Yes, thanks you, and apologies, sort of.
After posting I discovered that if you add the ".js" extension to the typescript import statement,
the code will be generated correctly (will not change) and typescript itself also keeps working with debugging option.
.
It still seems strange to me that you have to refer to not-yet-existing *.js files from their corresponding *.ts fles,
but hey, it works :-).

@borfast
Copy link

borfast commented Jan 4, 2021

TypeScript transpiles to JS but then generates broken (modern) JS code.

?

It works fine

example.ts

import { Example } from './example.js';

compiles to

example.js

import { Example } from './example.js';

This same argument has been made before in this thread but it still doesn't make sense. You can not import something from a compiled file, especially one that hasn't been created yet. No other programming language allows that. Java doesn't allow you to import something from a .class file. C and C++ don't allow you to #include something from a .o file.

@db984
Copy link

db984 commented Jan 4, 2021

example.ts

import { Example } from './example.js';

I'm writing in typescript; importing something from a local path in the same project that only contains typescript files. How does appending a .js to the import statement make sense to you? We're not writing any javascript and there's no javascript file in the folder being referenced?

The .js file being referenced doesn't exist; and won't exist until after it's been transpiled to js, and when that happens in many cases it'll be stored somewhere else. Source code shouldn't be referring to it's own build artifacts.

At the very least, if I'm going to reference importing from another typescript file by name, it should be:

import { Example } from './example.ts';

I further agree with the complaint that I shouldn't have to put the extension at all; let me just refer to ./example, and the transpiler can find the relative .ts file. And the transpiler should be responsible for appending .js in the transpiled output,

We really shouldn't have to provide the ".js" in the .ts source code.

@FunctionPoint
Copy link

FunctionPoint commented Jan 4, 2021

For the record, I totally agree with @db984
that this is a bug / design flaw that should be fixed asap.
But the workaround that works for me is importing *.js modules from the *.ts files,
even if they don't exists yet with a clean build.
FYI: I'm using latest: VSCode 1.52.1 and TypeScript 4.1.3, Edge 87.0.664.66.

@pauldraper
Copy link

pauldraper commented Jan 5, 2021

You can not import something from a compiled file, especially one that hasn't been created yet. No other programming language allows that. Java doesn't allow you to import something from a .class file.

No, that's exactly what Java does. Exactly.

import org.example.Example, means that the .class file is (or will be) located at org/example/Example.class on the classpath. Whereas the file structure of .java sources doesn't matter in the least...every .java source file from every package could be in one directory; javac doesn't care. Imports refer to .class file structure.

C and C++ don't allow you to #include something from a .o file.

Which makes sense because C/C++ includes are done as text preprocessing on the source files. Whole different approach, whole different ballgame. Forget knowing about compiled files, gcc -E and #include is a templating language isn't even aware what actual C is.


If you're requiring the "file to exist", you should also have a problem with the "non-existent file" lodash in

import * as _ from 'lodash'

The answer is that lodash isn't a file, it's a module specifier.

TypeScript doesn't change module specifiers. You can use lodash, lodash/index, /home/me/project/node_modules/lodash/index.js, https://example.org/js/index.js, etc. and TS respects your choice.

TS doesn't know anything about JS file<->module specifier relationships. It just knows how to resolve TS types from module specifiers. TypeScript plays around with extensions (.js, .ts, .jsx, .tsx, .d.ts) and directories (@types) and even uses selective parts of files (declare module 'lodash' {})

If you import from lodash or lodash/index.js, TypeScript will attempt the various extensions and directories in it's algorithm to find the types for that JS module. This is how it has always been, for every import ever.

I further agree with the complaint that I shouldn't have to put the extension at all

Then use a module loader that works with extensionless module specifiers.

But if you're interested in a module loader (native ES modules) that requires the exact path of the JS modules, know that TypeScript in fact supports using the exact path of the JS module. (Said differently, TypeScript supports locating TS types using the exact path of the JS module.)

@MicahZoltu
Copy link
Contributor

Yes, thanks you, and apologies, sort of.
After posting I discovered that if you add the ".js" extension to the typescript import statement,
the code will be generated correctly (will not change) and typescript itself also keeps working with debugging option.

It still seems strange to me that you have to refer to not-yet-existing *.js files from their corresponding *.ts fles,
but hey, it works :-).

@FunctionPoint as an alternative option, you can use a compiler plugin to add the extension at compile time: https://github.com/Zoltu/typescript-transformer-append-js-extension

@borfast
Copy link

borfast commented Jan 5, 2021

@pauldraper,

No, that's exactly what Java does. Exactly.

No it's not and you know exactly what I meant 🙂

What Java allows us to do is to import source files, not compiled files. It may so happen that in the compiled Java bytecode it does reference a file ending in .class (probably not but I don't recall how it works) - but that's the compiler's decision, not ours. This is the main point you're missing: it's not about what letters you type after a dot; it's about forcing us, developers, to do something that is inherently wrong, which is to do the compiler's work by referencing build artifacts. It's not our responsibility, nor should we touch this in any way.

@db984's reply is spot on.

@db984
Copy link

db984 commented Jan 5, 2021

Where @pauldraper writes:

If you're requiring the "file to exist", you should also have a problem with the "non-existent file" lodash in
import * as _ from 'lodash'
The answer is that lodash isn't a file, it's a module specifier.

A bare module specifier is a completely separate case. Here we are clearly relying on the compiler/runtime and project configuration to help it find a module named "lodash". Perhaps the file being imported is in ./node_modules/lodash/index.js or perhaps its somewhere else. But its pretty clear that all the source code says is that its in the "lodash" module.

When I import from '../../services\core\example' without any extension, to me at least, that looks like an import of a module named example from a specific location. I'm telling it where to look for the example module, but still not giving it a filename. And that works, and is logically consistent, because that is the path to where the source code for the module named example lives but I'm still relying on the compiler and runtime etc to figure out the file name to import. I'm just naming a module and saying where to look for it.

But when I import from '../../services/core/example.js' with the js extension, that now looks an awful lot like a specific file in the source tree, given explicitly by filename. Yes, there is source code for a module there named example, but its in a file called example.ts that I expect will be transpiled to example.js in the output folder at some point, and that is an extremely clumsy solution; because nowhere in my source tree do I have anything called example.js so it doesn't make a lot of sense to be referencing it.

To argue that '../../services/core/example.js' is also really a just a module specifier may be technically correct, but its un-intuitive because it's also clearly a file reference and it doesn't resolve the complaint that '../../services/core/example.js' doesn't actually exist.

It seems far more logical to me that typescript should explicitly support typescript source code esm modules that are part of the project and allow you to reference '../services/core/example.ts' with a ts extension, and when it transpiles the referenced ts file to a js module it can swap in the .js extension in the transpiled output. Then I'm referencing a file that exists in the source, and leaving it to transpiler to transform it to a suitable valid module reference in the output.

And again, I would go even further and also allow you to leave the extension off entirely, and it will look for the module specified at that path, much as it does for commonJS modules, even though that's not in the javascript esm standard. It's doing a transpilation step anyway, so it can do the legwork of resolving the the module specifier to a file reference. I'm using typescript because it makes life easier after all.

@shicks
Copy link
Contributor

shicks commented Jan 5, 2021

I agree that in an ideal world, TypeScript could take total ownership of the import paths and remap them appropriately.

But tsc doesn't always (often) have visibility into where the *.js artifacts actually live - its resolution is looking for *.d.ts files in many cases, so any such rewriting would be spotty at best. Given the inconsistency, the next best thing is to just not touch it at all, which is the current behavior.

@db984
Copy link

db984 commented Jan 5, 2021

its resolution is looking for *.d.ts

a) This already deviates from javascript; so 'not touching it at all' is already not accurate.

b) It's been working fine for project relative imports in commonJS all this time, with very similar constraints so I'm really not sure why you think this is a significant challenge where support could only be "spotty at best".

As near as I can tell the only real change is that esm module resolution standard requires the explcit .js extension when referencing importing a js file from a relative location where as the commonJS standard specified that it would search filename.js then filename.json etc automatically in this case.

@RyanCavanaugh RyanCavanaugh added Declined The issue was declined as something which matches the TypeScript vision and removed Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. labels Jan 5, 2021
@RyanCavanaugh
Copy link
Member

Well I've read all 385 comments again now as part of a FAQ update and here are my main takeaways:

  • We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit
  • .js file extensions are now allowed, which was not true when OP was written, so the issue as described has been fixed
  • We are 100% committed to not rewriting JavaScript code as part of non-downleveling compilation. This is how everything else in TS works; see also this comment in a related feature request, and this comment in a related feature request. We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit
  • Everyone should read this comment from this thread as it accurately summarizes the rest of the discussion IMO

Experience on these sorts of threads has shown that discussion tends to just remain circular at this point, so I'm going to lock to avoid notification noise for commentors and repo watchers. We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit.

@microsoft microsoft locked as resolved and limited conversation to collaborators Jan 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Declined The issue was declined as something which matches the TypeScript vision Domain: ES Modules The issue relates to import/export style module behavior Suggestion An idea for TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.