Need possibility to configure suffix (not only extension .js)

[viT-1]

Is this plugin use compilerOptions > paths to generate import relative to root of webserver Uri paths?

Can i configure this plugin to get relative paths like this:
import ... from '@common/Greeter'
to
import ... from '/commonFolder/Greeter/index.js'
or even custom straight path (same name as leaf folder)?
import ... from '/commonFolder/Greeter/Greeter.js'

[MicahZoltu]

The design goal of this plugin is specifically to address the issue of browsers demanding a file extension while ts-node demands a no extension. I would prefer not to have this slowly grow over time, and instead would rather see separate transformers that each do one task well (such as path mapping transformations).

That being said, I don't think it would be particularly hard to create a plugin that does what you want. My recommendation would be to take this plugin as a starting point (it is Unlicense so you don't even need to give attribution!) and then tweak it. The hard part is going to be figuring out how to access the paths mapping (which I'm guessing is how you are doing @common => /commonFolder) from a custom transformer.

Transformers run in sequence, and I think a paths transformer could be run before or after this one so if you do have a paths transformer it should be able to work with this one without trouble.

[MicahZoltu]

Oh, actually... what you want already exists! https://github.com/LeDDGroup/typescript-transform-paths

[MicahZoltu]

I'm going to close this since it appears another plugin provides the exact solution you are looking for and it should work fine in concert with this transformer. Let me know if you find that they aren't compatible, or if you think I have misunderstood your issue!

[viT-1]

I tried today typescript-transform-paths, it's very useful for node with commonjs transpilation. I don't try yet typescript-transform-paths in browser.

I think that generated relative paths like

// /commonFolder/Greeter/index.js
export { default } from './Greeter';

will not resolved as uri.

[viT-1]

But anyway, this functionality should be realised as another typescript-transformer-...

[MicahZoltu]

Browsers can resolve relative paths. :) If you have import { Foo } from './foo.js' in a browser module, it will fetch the file foo.js from the same place that it fetched the current file.

[viT-1]

But with typescript-transform-paths i have only ./commonFolder/Greeter not ./commonFolder/Greeter/index.js (as yours './foo.js')

[MicahZoltu]

Ah, yes. You would need a transformer that turns modules references (which node resolves by looking for a package.json and then reading the main field from it) into references to the main file directly. This would require the transformer follows the same resolution logic as node. Unfortunately, I believe that node's resolution logic is actually quite complicated, far more than "package.json > main" so such a transformer would be somewhat complicated.

You may be able to ask TypeScript to resolve it for you? They already do NodeJS resolution, so somewhere in the TypeScript library there is code for node module resolution. Perhaps if you can find that you can just call it?

[viT-1]

Many words from Microsoft was written =)
But it seems that they not want to
and we forced to use ttsc with transform-plugins instead of tsc.
I did not find a single mention from Microsoft that they plan to implement this feature for using <script type="module"> with transpiled code from the box.

[MicahZoltu]

I believe their thought process is that TypeScript's job is to compile TS into JS. It is not TypeScript's job to do dependency management or bundling, and those tasks are for other tools dedicated to that task.

[viT-1]

Exactly! Therefore, they strongly recommend using for example SystemJS resolving. But i want to add es6 modules (in dev deploy) straight to the browser without SystemJS. We are close to solving the problem without using webpack/rollup/etc...

[MicahZoltu]

I solved this problem with a manual (but simple) build step:
https://github.com/Zoltu/recoverable-wallet/blob/micah/sample-site/build/build.ts

It just copies the files from NPM packages into a vendor folder before building.

[viT-1]

My project uses gulp and gulp-typescript for deploying
I think my variant is second step after typescript-transform-paths: gulp-replace regexp for getting finally path.

[viT-1]

@MicahZoltu After v2 of typescript-transform-paths
I'm trying to move gulp task to using your plugin.
All js files by your plugin working now have js extension, but not from "./something.conf"

Steps to reproduce:

1. npm run deploy.dev
2. npm run www.dev
3. Open browser with http://localhost:3000/
4. Check console for url resolving error about conf files
5. You also can see deployed file dist/common.blocks/Greeter/Greeter.js which import wasn't transformed correctly.

[MicahZoltu]

If I understand correctly, what you are experiencing is expected behavior for this plugin. It is only meant to convert import ... from './something' to import ... from './something.js'. It explicitly avoids renaming anything else.

[viT-1]

@MicahZoltu Exactly! And strangely your plugin is not working properly in such case (just try). I don't need to renaming, only adding extension. File can be named some.thing.ts, imported in src files as import ... from 'some.thing' and need to be imported after plugin transforming as import * from './some.thing.js'

[MicahZoltu]

Ah, you are referring to these lines:

typescript-transformer-append-js-extension/source/index.ts

Lines 26 to 27 in 3df3f78

	// only when module specifier has no extension
	if (path.extname(node.moduleSpecifier.text) !== '') return false

This was an intentional trade off. There are lots of situations where one would want to import not-JavaScript files like import 'style.css' or import 'site.html'. Rathere than trying to guess all possible extensions that people may use, I opted to instead just assert that this plugin only converts filenames without a . in them.

It would be quite easy to fork this repository and take those two lines out if you always want to add .js to files, even if they already have an extension.

Alternatively, it would be possible to add some sort of configuration that allows you to specify what extensions to exclude and then include all others. The reason I haven't done this is because adding a mechanism for configuration would turn this 30 line plugin into 100s or 1000s of lines and likely require bringing in a bunch of dependencies.

[viT-1]

I think it would be a good idea to have configuration like tsconfig.exclude array.

It would be quite easy to fork this repository and take those two lines

No, in my case easier to use task of gulp-typescript, but I prefer to take out standart behaviour (which I can't get from tsc) to your plugin.

[MicahZoltu]

I 100% support a fork of this repository that adds configuration! It is unlikely that I'll add it though since the effort of adding configuration to this project, and the side effects that brings, is likely far higher than the benefit to most users.

Note: There are 5 forks of this project, and this question has come up before. You may want to poke through those forks and see if any of them implemented what you want.