I am working on a project under NodeJS that uses ES6 imports/exports (hence having set type: module in its package.json) and want to automate some tasks using Grunt. Now, I absolutely love grunt, but it appears to me that even in 2022 it is still not able to work nicely with ES6 modules? I always get an error saying "require() of ES Module /vagrant/Gruntfile.js from /vagrant/node_modules/grunt/lib/grunt/task.js not supported."
I understand where this is coming from, and I do understand there are workaround options - in particular, renaming Gruntfile.js to Gruntfile.cjs and passing it to grunt with the --gruntfile command line option. But that is incredibly annoying - it makes the command six times as long as it would be if I could just run grunt and be done with it. Pretty much the same goes for transpiling with something like Babel: That is exactly the kind of thing grunt is intended to handle in the first place, so it feels a bit like the horse riding the jockey. I feel like this should "just work".
Am I missing something here, or is grunt really unable to handle ES6 imports out of the box?
Actually, looking at the grunt github page it appears that a recent commit has addressed it.
I guess this issue will therefore be resolved in their next update.
Related
I'm trying to fix this problem for 6 hours now and I'm slowly starting to lose my mind, so please excuse my generic question.
First of all I am using:
Node: 8.10.0 | npm: 5.6.0 | Yarn: 1.5.1
I just upgraded my project to Node v8 and npm refused to install all dependencies, so i installed yarn which fixed the issue immediately.
My sources are compiled using Laravel Mix which utilises Webpack, Babel, ... internally.
Installing and compiling of my sources works perfectly fine now but for some reason my compiled js file is not working anymore (even if I downgrade to the previous Node version - 6.10.0).
Uncaught TypeError: fn.bind is not a function
at nativeBind (admin.js?id=8c4a6887899977ba8021:72515)
at initMethods (admin.js?id=8c4a6887899977ba8021:75849)
at initState (admin.js?id=8c4a6887899977ba8021:75617)
at Vue._init (admin.js?id=8c4a6887899977ba8021:76936)
at new Vue (admin.js?id=8c4a6887899977ba8021:77037)
at Object../resources/assets/js/admin.js (admin.js?id=8c4a6887899977ba8021:83350)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at Object.1 (admin.js?id=8c4a6887899977ba8021:83790)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at ./node_modules/babel-loader/lib/index.js?{"cacheDirectory":true,"presets":[["env",{"modules":false,"targets":{"browsers":["> 2%"],"uglify":true}}]],"plugins":["transform-object-rest-spread",["transform-runtime",{"polyfill":false,"helpers":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/components/Autocomplete.vue.Object.defineProperty.value (admin.js?id=8c4a6887899977ba8021:63)
I have aboslutely no ideas what this error means let alone what causes it.
I know that the error message is pretty generic and could probably mean a lot of things but hopefully someone knows what it means given my context.
Thanks!
#Ortomala Lokni's answer pushed me in the right direction.
For some reason I thought my problem was related to my build scripts, npm, webpack or anything of that sort, which - of course - it was not.
Event though it wasn't really an API change as he suggested there was simply a wrong call to the VueJS constructor in my JS file which, for some reason, had been ignored by a previous release of VueJs but apparently not by the current one.
For anyone experiencing some weird bugs that just don't make sense I recommend the following:
First of all: Determine what really is your problem - if it compiles it is most certainly not related to your JS build
Comment out all of your JS code in your main file
The error should be gone at this point
Narrow down the error by trying to uncomment line by line (or block by block) and test your code after each uncomment
Even though this steps might seem obvious you can easily forget about such simple thing because of the million things that could possibly break when working with modern JS.
Sometime when you upgrade libraries you have to adapt some code. As Javascript is not a typed language, the problem does't appears at compile time but at run time.
In your case, I suppose that you have a problem similar as this one.
Check which libraries yarn has upgraded and verify if some API has changed.
I have been working with TypeScript off and on for two years now. I am not an expert by any means, but I've spent some time in the eco-system: with VS2015 and node tools, with VSCode, and at the command line with tsc and typings (also used by VSCode).
And I have struggled with the correct way to get static typing and auto-complete etc in the code I've been writing.
I have a repo I maintain (EasyNodeQ) which was the start of my TypeScript experience and I sort of got that to a manageable place with ///reference and DefinitelyTyped. But any time I tried to use that within another project I had issues.
Things got a little better when I started using typings (rather than downloading the *.d.ts files myself) and especially with the ambient flag.
But I still have lots of issues trying to use that package within other projects. Depending on the approach I take, I get lots of Duplicate Identifier's, or module not found's or...
And this can range from Node definitions, to packages I use in both places (like node-uuid).
All I want to understand is this: how to I structure EasyNodeQ so that as I'm working on it, I get the static typings benefits of TypeScript but also have it be seamlessly included in other projects which can then also get these benefits?
Does that make sense?
The basic use cases are: npm install a package and get its typings, use my EasyNodeQ package and get its typings, work in a new project that uses EasyNodeQ and other packages and easily manage those typings.
Preferably in a VSCode or command line way...
This is with ES6 and the latest version of TypeScript (though an answer that works with ES5 would be nice - just not required).
I hope this makes sense. I've looked all over and I can't cobble together an answer that works.
UPDATE
I'm not convinced I've done this the "right" way, but it's working now so I thought I'd post the various things I've done (generally in the order I think they mattered and not inclusive because I may have forgotten some).
I hadn't npm'd the dependency package (easynodeq) and was just using a git url in the package.json - so I created a proper npm package and now install that package from npm
Instead of trying to use Bus.ts as both code and definition, I made Bus.js the "meat" of the npm, and built a Bus.d.ts file (also in the npm)
Embraced typings, using non-ambient definitions where possible and a mix of ambient definitions downloaded (via git) from DefinitelyTyped and "--ambient" definitions for the rest (because I'm still confused about the difference). The ambient definitions ended-up being the majority: node, express, serve-static, express-serve-static-core, mime, amqplib, when vs just bluebird and node-uuid, even though most of them were found by "typings search ..." Am I doing something wrong?
Modified package.json to also do "typings install"
Cleaned-up the git repo
There are several ways to make this work today. As you mentioned, using Typings works for definitions that aren't natively included in their NPM packages. For ones that do, you can using the typings field in package.json and it'll work with node module resolution. When you combine this together, you can publish packages that use both typings.json and relies on packaged typings - though this now forces your consumers to be using Typings to install the definitions. None of this, however, works with "ambient" definitions as they can not be namespaced properly.
This may be useful: https://github.com/typings/typings/blob/master/docs/faq.md#should-i-use-the-typings-field-in-packagejson. There's also dozens of examples I have using both workflows: https://github.com/blakeembrey/change-case/blob/master/package.json#L6 which uses node module resolution all the way down and https://github.com/blakeembrey/popsicle/blob/master/typings.json which uses Typings instead. Using Typings is only possible because it works to create namespaced ambient modules for you, but they won't conflict.
Due to the lack of support of modules or packages under development in npm I have decided to use webpack's components which from the look of the example provided here webpack/examples/components seems to be exactly what I am looking for. However there is no example how to actually use the example. Drawing from webpack's convention I thought that:
webpack/examples/components> webpack component.json > bundle.js
would do the trick but nope I get an error. Tried some other stuff like putting an entry file and an output file in the webpack.config.js but no luck there either. Has someone ever use it, does it work and most importantly how to start it?
I'm using coffee-script 1.7.1 (or I want to use it). Can't make it work, though.
first line of my server.coffee file is require 'coffee-script/register' and I get the oh-so familiar error SyntaxError: Unexpected string. On version 1.6.3 all was well.
In a different project I've successfully used coffee 1.7.1 when the starting file was server.js, but don't want to do it here.
Has anyone made this work? Preferably without making some sort of weird workarounds.
I'm using coffescript 1.7.1 and require 'coffee-script/register' with server.coffee.
Not sure if this applies to your situation, but I spent many hours on a similar error before I realized that I was launching my app from the wrong instance. For example, /usr/bin/coffee instead of /usr/local/bin/coffee.
which coffee gave me the correct path.
I think that you only will need to require coffee-script/register when you are writing JS and want to load a coffeescript file.
The hogan.js template package that express provide is hjs, however, that package last update was a year ago, and the repo at github got issues opened also a year ago (though not really crucial ones).
There also seems to be more than one hogan.js package for express tempting at npm which left me confused!
If you see hjs source code, it's only 63 or so lines and it require hogan.js to work, so it's just a wrapper to make it work on express.
The one I used is hogan-express which is also a wrapper for hogan.js (it's required in package.json) and it's no more than 150.
My point, to try to clarify things, it's that the important module is hogan.js all the rest modules to integrate in express are just wrappers. I believe is also worth to give a try to the consolidate module which also support Hogan.
By looking to githubs stars (not necesarily quality indicator) you will see
consolidate (*548) > express-hogan(*48) > hjs (*8)
If you are wondering why hjs was the "chosen" for the express command line the answer is this pull request You can see by your self what it takes to implement another module. So may be some one should report if hjs is giving problems and there is a better alternative. It's not hard to change it in express.