wrong order in webpack "resolve"

[farfromrefug]

In all webconfig using typescript there is an issue with the order of the resolve extensions.
an example:
https://github.com/NativeScript/nativescript-dev-webpack/blob/master/templates/webpack.typescript.js#L72

Typescript is put first. Which means that if there is a the ts and the js file at the same location, webpack will try to package the ts file. This will make the bundle compilation fail. The fix is really easy, put .js before .ts

You will ask when will this happen? Well for me it happens while developing modules. I use npm link for easy development. So I have ts and js file in the same place. I got the error with angular ngtools webpack

[DimitarTachev]

Hi @farfromrefug,

The .ts extensions are before the .js ones in order to get your ts files watched and compiled. If we swap this order, your ts files should be compiled manually.

We are also using the npm link flow in the plugin development. I suppose you are getting an error for missing module ts files in your app. I suggest you try including these files in the ts compilation of the app like we do here (don't forget to exclude the node_modules). Bear in mind that you should also update your references.d.ts in order to target the same definition files as your module (take a look here). If you are still getting an error, you may also need to set your webpack.config resolve.symlinks property to true.

[farfromrefug]

@DimitarTachev It s not a good solution for me. You can see the source of the issue here:
NativeScript/nativescript-angular#1430

[DimitarTachev]

@farfromrefug maybe the best solution would be changing the extensions order only for node_modules but as far as I know, that's not possible. Changing the extensions order for all folders is not an option as it will cause a lot of typescript related issues for the regular NativeScript users (as I already mentioned, their ts files won't be compiled out of the box and they will constantly see an older version of their app till a manual typescript compilation).

That's the reason we use the above-mentioned approach in our plugins. Why do you think its not a good option for you? If you have an idea for a better solution, it will be highly appreciated.

[farfromrefug]

@DimitarTachev I already use what I think is a better solution for me even if it Is a little bit tedious.
I use resolve.alias to tell Webpack to use js instead of ts for those files. It is not perfect but at leat it has no side effect once I remove the npm link and start to work with my published module
I don't like the modifying the tsconfig your way because it will persist once you remove your npm links.

[DimitarTachev]

@farfromrefug I didn't realize you are developing your plugins directly in your app where you need to refer them from npm at a later stage. You're right about this side effect and that's the reason we use the tsconfig approach only in the demo apps of the plugins (its even included in the demo of the official plugins seed) where you always need the npm link approach for a better performance during the plugin development and testing.

If you need to test a local version of a plugin in another application (different from the plugin demo), its a lot easier to pack the plugin and refer its tgz in the application.

However, if you like mixing the plugins and apps development, you could use your workaround with resolve.alias or swap the ts and js extensions but I still suggest you have a clear separation by splitting your plugin and app development (follow the plugins seed for your plugins where you always need the npm link approach and use the plugins from npm or local tgz files in your apps).