Menu
I'm trying to integrate Durandal with node.js server using Typescript for defining modules both on server and client side.
The problem I've encountered is that Durandal is strongly dependent on RequireJS and AMD style of defining modules that I would like not to introduce on the server side, and since it uses RequireJS I don't have any chance to run CommonJS-ish modules on the client (default for node.js).
The final nail in the coffin is that I found no way of defining which files should be compiled as AMD modules and which one as CommonJS by tsc - it seems like a simplest solution.
I don't think separating client part and server part is an option, since a lot of code will be common to both parts.
So, my question is threefold:
is there a way to mix AMD and CommonJS modules in the same Typescript project (preferably using NodejsTools)
if not, is there a way to force Durandal to work with CommonJS files to load views/viewmodels and so on
if none of this is possible is it possible (and wise) to use AMD modules on node.js server
Any ideas are highly appreciated
795
Yes, you can use it in a same manner that you would use it in Javascript. Typescript is superset of Javascript, all things possible in Javascript are also possible in Typescript.
It is not deprecated.
Yes this is possible. Since all files will be transpiled, it is necessary to output the resulting JavaScript into a different directory otherwise the input . js files would be overwritten1.
Importing from ESM and CommonJS to CommonJS Since require() is synchronous, you can't use it to import ESM modules at all! In CommonJS you have to use require syntax for other CommonJS modules and an import() function (distinct from the import keyword used in ESM!), a function that returns a promise, to import ESM.
This is more of a long comment than an answer
I've been looking at the same problem, and I did try grunt-ts ,gulp-ts, Webstorm file watchers, cmd line scripts , Everything but Visual Studio as I 'm afraid to rely on the IDE for the build process (Webstorm watchers are an exception as its the same as a grunt or any other watcher, easy to replicate , and its just handy to try configurations); I'm currently using internal modules but compiling only the 'exporting' modules with file filters (extension based ,is the cleaner) and tsc load the chain when they are referenced ;
I have different output targets based on what I'm trying to achieve, as in node, browser, angular, testing, mocha, jasmine, etc...
like in:
/MyModule
myModule.ts
myModule.d.ts
myModule.mdl.ts (exports amd)
myModule.export.ts (exports commonjs)
myModule.test.ts (exports mocha test, no KARMA!)
etc...
not relying on Ts ' export module' ability
It works but ... But I'm not 100% happy , to many files .... it smells ... too many targets Gruntfile is difficult to read(too big) , I need to remember or document how it works until I got the time to fully automate it (if reasonably possible)
I think the options below make more sense on DRY and KISS sense but I'm also not 100% sold on the boilerplate needed.
Typescript modules should be templatable so when they compile the module could have the 'shape' I want without to rely on extra build steps
Some Options to don't need to compile multiple targets , or file duplication
UMD (Universal Module Definition)
Browserify
amdefine
RequireJs in Node
Requirejs LOADING MODULES FROM COMMONJS PACKAGES
24
is there a way to mix AMD and CommonJS modules in the same Typescript project (preferably using NodejsTools)
Yes. Use grunt-ts. See https://github.com/basarat/demo-fullstack/tree/master/src specifically the gruntfile common files : https://github.com/basarat/demo-fullstack/blob/master/src/Gruntfile.js#L4-L6 commonjs : https://github.com/basarat/demo-fullstack/blob/master/src/Gruntfile.js#L26 amd : https://github.com/basarat/demo-fullstack/blob/master/src/Gruntfile.js#L37
89
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
