Ability to bypass ts-transpiler for release builds [FR]

[aminya]

If this is a feature request:

Can we have a way to bypass ts-transpiler for the release builds? We want to use bundlers such as Parcel, etc for the release build which results in a faster load time, but we want to use ts-transpiler during development.

[smhxx]

In theory, it should be possible. To be entirely honest, I've never actually liked this package for that exact reason. It certainly has its uses, but forcing the user to download the entire TypeScript compiler, plus this shim, just to convert your source code on the user end just reeks of the type of bloat that people make fun of Electron/Atom for. It sort of originated as a proof of concept, and I can see why it gained traction due to ease of development, but my personal opinion has always been that using it in production is... sub-optimal.

I'd have to think about what the best way to do this would be, without needing to get changes to Atom itself accepted. I think that you could list atom-ts-transpiler and typescript as devDependencies rather than a dependencies, and as long as you don't publish any files that match the blob in your package.json (i.e. any .ts or .tsx files,) it should never actually get called, so you won't run into any errors due to the missing package. Having the atomTranspilers field in your package.json shouldn't break anything on the user's end as long as you don't publish anything that's going to trigger the transpiler to run. As long as your publish process is converting everything from TS to JS, I think that the missing transpiler shouldn't cause any issues. Might require a little investigation or testing, but I think it can be done.

[smhxx]

Reading the discussion in the other thread, I now see what the issue is. I'm not sure how this would be fixed from within atom-ts-transpiler, although there is probably a workaround of some sort that would achieve what you're trying to do. I'm thinking perhaps you might make one unified entry point as a .js file, which then points to /dist/main.js if such a file exists, or /src/main.ts if it doesn't; something along those lines. Alternatively, two other options would be to use a script or hook to modify the "main" field of your package.json during the build/publish process; or to have a dummy /dist/main.js on your development branch which simply points to /src/main.ts for while you're developing, and allow your build process to overwrite it before pushing to master. Most of these aren't necessarily the "cleanest" solutions, but short of adding a feature to Atom that allows separate entry points for dev/production modes, I think the best option would probably be some sort of dynamic approach like that.

[smhxx]

Actually, that first option is what markdown-preview-plus does. Might be worth considering.

[smhxx]

I don't think that there's much that can be done to ease this sort of usage on our end, at least from a code standpoint, but I'm going to leave this open because I do think that there's merit in adding some documentation and/or code examples of development-only usage of atom-ts-transpiler. I think it would be great to help devs who want to write their packages in TypeScript to do so without needing to burden the end-user with the extra dependencies and higher first-run loading times associated with on-demand transpilation. For tiny "hobby" packages, it's probably fine, but with bigger packages like git-plus, markdown-preview-plus, and pdf-view-plus now using it, it would be great to include some "best practices" for setting up a TypeScript package.