12 ms·
For anyone using TypeScript to build your Node.js code, you can now switch your target to es6/es2015 in your tsconfig.json: { "compilerOptions": {
by altano 10y ago
For anyone using TypeScript to build your Node.js code, you can now switch your target to es6/es2015 in your tsconfig.json:
{
"compilerOptions": {
"target": "es2015",
"module": "commonjs"
}
}
Assuming you're not using that 7% (http://node.green/ http://node.green/) :)
Just make sure to update your package.json to take a hard dependency on Node 6+ if you do that:
{ "engines" : { "node" : ">=6.0.0" } }
This will make it so that ES6-compat is assumed and TS won't transpile ES6 functionality, but it will use commonjs for modules, which means your TS will almost be a 1:1 mapping with the compiled JS and everything should just work.
- dudus 10y agoThis should be ok 93% of the time
- jkrems 10y agoPersonal pet peeve: Please don't set the node engine field in npm packages. It potentially breaks your package whenever there's a new release candidate because `node@7.0.0-rc.1` is less than (!) `node@6.0.0` when it comes to npm's handling of this field.
- kevinastone 10y agothat's surprisingly dumb, isn't it? semver.satisfies('7.0.0-rc1', '>=6.0.0') false
- nilliams 10y agoNot really, you get a warning that said module might not support this 'release candidate' of a major breaking version.
- geofft 10y agoWeird. https://docs.npmjs.com/misc/semver#prerelease-tags https://docs.npmjs.com/misc/semver#prerelease-tags I guess the argument is that, if you're going to use ">=6.0.0" to choose a version of node.js, and your options are 6.1.0 and 7.0.0-rc1, you don't want a random release candidate. But if you're going to use it to verify an existing version of node.js, a 7.0.0-rc1 that someone else chose should be considered acceptable. Their semver rules can't distinguish these two cases. PEP 440 seems to handle this by decoupling the prerelease rules and the version-comparison rules: https://www.python.org/dev/peps/pep-0440/#handling-of-pre-releases https://www.python.org/dev/peps/pep-0440/#handling-of-pre-re... "Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release."
- Touche 10y agoMajor releases are potentially breaking
- drchickensalad 10y agoWhy does it act like this?
- jgillich 10y agoNpm doesn't actually enforce this field, unless engine-strict is set (off by default).
- chrisfosterelli 10y agoIndeed, and the latest versions of npm actually ignore engine-strict as well.
- dschiptsov 10y ago> because `node@7.0.0-rc.1` is less than (!) `node@6.0.0` It is so PHPsque. No sane people should use it for anything serious, except some lightweight browser scripting.
- altano 10y agoSooo that's like, an npm design flaw then? If you don't specify the engine field, someone using an older version of node will just get incorrect failures and think your package is broken. I'd rather specify the engine and give a clear error to all users on a version of Node.js older than 1 day than to make it work for users on Node RCs. Although it would be nice if npm made it possible to support both sets of users.
- kodfodrasz 10y agonode.js and JavaScript in general make PHP look a well designed decent language and ecosystem. I cannot grok how can people chose this stack to create any product in it.
- homogeneous 10y agoWhat does this type of condescending bile add to the discussion? Thousands of companies successfully use PHP and node to write excellent software every day. If you despise node so fervently, why are you even engaging in a thread about the latest node release? Personally, I prefer ruby whenever its an option, but I've worked with node in the past and it's a decent platform that worked very well for the company (a commercial app servicing about 840k api and page requests per month). I just don't understand the hate.
- aviraldg 10y agoSo negative opinions about '*' should never be expressed? JavaScript is a terrible language, and imho es2015 fixes a lot of broken stuff in the only backwards-compatible way it can. That said, I find the entire micropackage culture around npm and node, coupled with the hundreds of packages that typically constitute build scripts for even a smallish node project make me realize just how brittle it is compared to competing platforms.
- nilliams 10y agoThere's a difference between being negative with specific complaints versus hyperbolic, drive-by FUD. Regarding your own complaints with Node. You're over-generalising. Nobody says you must use small modules. Larger libraries and frameworks exist. Same goes for build scripts. Also read this to get more context on small modules: https://github.com/sindresorhus/ama/issues/10 https://github.com/sindresorhus/ama/issues/10
- homogeneous 10y ago"Negative opinions" are fine. Heaping on condescending substance-free exclamations of ridicule in the middle of a thread about a specific issue regarding a platform you don't even use is just toxic arrogance. Your "micropackage" complaint is daft; if you don't like small modules don't use them. Why is the language to blame for free, open-source code that you don't have to use? How is this even a legitimate complaint? You don't need hundreds of packages for anything and you can find examples of this in any language.