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.

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.

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

@justinfagnani @rictic

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

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

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.

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?

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..

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 :-).

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.

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.

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.

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.)

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

@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.

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.

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.

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.

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.