some thinking points
Closed this issue · 5 comments
this is a awsome project!
I think nakedJSX can support deno and make dependencies as few as possible.
Looks like there are still too many deps, the cli can handle a lot of deps but not the core.
Most importantly, I think most of us will need ".tsx" support from "tsconfig" or "deno.json".
Thanks for taking a look and for your kind assessment.
So the starting number of deps is 210, coming from 18 direct dependencies (8 of which are @babel/*).
A huge contributor to the number of deps is @babel/preset-env, used to to target the generated client JavaScript at whatever browserslist setting you like. I just checked and removing this one dependency brings the number down to 102! So I think there's a good case for introducing a 'client javascript' plugin system and shifting @babel/preset-env to an optional plugin.
If I also remove Terser, used to compress client JavaScript, then we are down to 96 dependencies. If I introduce a new kind of plugin to make @babel/preset-env optional, then Terser could also be shifted to the same plugin system.
I think the other contender for removal is Rollup, used to compile page JS which is then executed to produce the HTML file, and also to compile the client JS. It would take a bit of work to replace, but it was already on my mind as something to look at removing given that NakedJSX is already controls all of the import resolution itself. Removing all of @babel/preset-env, Terser, and Rollup would bring the dep count down to 88.
Deno is something I am only dimly aware of but I intend to test it at some point.
Typescript support is something that should be simple to add, probably just adding another babel plugin. But I've not looked at it yet.
So getting typescript to work was indeed just a matter of adding @babel/preset-typescript and making sure that babel was configured to look at .ts and .tsx files.
However, the vscode dev experience isn't ideal - vscode will show a problem for every import inside a TypeScript file. This is because NakedJSX performs its own non-standard module resolution during compilation. I believe to prevent vscode from complaining I'd have to implement a TypeScript language server plugin, and then require that users add it to the plugins section of tsconfig.json - not ideal
Another option might be to generate a tsconfig.nakedjsx.json file with path mappings for each import used in the project, and then asking the user to add "extends": "tsconfig.nakedjsx.json" in their tsconfig.json file to inherit the mappings.
I might pause this until I have a user that actually wants to use TypeScript on a NakedJSX project so I can work with them on finding the right solution to this.
FYI - NakedJSX 0.14.0 has been published with initial support for TypeScript. I'll work a way to deal with the 'vscode problems view' issue once a user is using it and complains about it.
(I should also point out that if using @nakedjsx/core directly, then unless you're using the express template engine mode then it would make sense to add @nakedjsx/core as a devDependency only.)