That was expected, sadly. It's not an easy task.
In the meanwhile, Node community might opt to use another extension to tell CommonJS and ES2015 modules apart. I really hope it won't happen.
That's the problem of not having tests: you should have noticed that in Firefox vendor-prefixed style properties begin with "Moz", not "moz".
Other suggestions:
- one could pass the perfectly valid property "font-smoothing", the function would have tried searching for "webkitFont-smoothing"... and failed, because it's "webkitFontSmoothing". So, camelCase the *whole* property, or make the documentation clearer that they should use "fontSmoothing" instead;
- it doesn't check for vendor-prefixed *values*, like "-ms-grid" for display. Unfortunately checking them isn't as easy, but that would be one of the perks of such a package. As it is, it's quite trivial and similar to many others (e.g.: https://www.npmjs.com/package/prefix-property).
This seems like an over-engineered CodePen snippet than a real package.
Moreover, it has nothing to do with JavaScrpt, just HTML and CSS.
Finally, let us decide if it's awesome or not (personally I think it's pretty bland).
> No, it's not that simple if you want to copy certain files from A to B and C, other files from A to D etc
Well, yes, it's *that* simple. If I have multiple destinations for the same file, I just have to .pipe again to another destination, that's it.
If I have to move other files to other destinations, I just have to do a new gulp.src and so on. On the plus side, I have the syntax of glob at disposal, and directories get created if they don't exist yet.
Are you even arguing that JavaScript doesn't have enough flexibility for that?
> I really don't see why I should be spawning servers or shell scripts etc from within gulp when it works much better just running them directly.
Strange, I'm sure I just perfectly explained why. Maybe I wasn't clear?
And no, they don't work "much better". At best they work as good.
The only times I rely on just npm scripts is for simple projects(?) that sprout and die in a day.
I remember when I saw a similar solution on Stack Overflow a while ago. It was frowned upon and for a good reason, since all expressions and branches were evaluated anyway.
But if there's a Babel plugin that transpiles those pseudo-components, that's another story and no harm is being done. Just two considerations:
- it won't work for TypeScript, not until TS will have a decent plugin system to work with (which is a *very* complex thing to do in this case, as the strenght of TypeScript relies in its monolithic understanding of the syntax extension it provides);
- they're actually, as I said, *pseudo*-components, which means they look like components but they're just syntactic sugar. This could be jarring for newbies, but also in the long term (with othe similar extensions) I think it would spoil the cleanness of JSX.
Unfortunately, every day that passes we're seeing the limits of JSX. For more complex compositions, it becomes more and more awkward to use (some say the ternary operator should be banned from being used in all languages altogether - there's even the "no-ternary" option for ESLint).
If those are the reasons, I'm even less convinced to switch to npm scripts.
Copying files is as easy as
gulp.src(toBeCopiedGlob)
.pipe(gulp.dest(destDir));
For the rest, Gulp tasks are just JavaScript functions. You're not actually forced to use gulp.src or any other method. You can start shell scripts, you can spawn servers, command livereloading, perform computations and evaluate conditions, etc. and, above all, you have a direct connection with the underling JavaScript application, as you can actually import its modules.
In addition to this, I have a consistent interface in which I can define parameters and help texts, and that's definitely a plus for anyone who's looking at the project's tasks for the first time.
If those are the reasons, I'm even less convinced to switch to npm scripts. Copying files is as easy as gulp.src(toBeCopiedGlob) .pipe(gulp.dest(destDir)); For the rest, Gulp tasks are just JavaScript functions. You're not actually forced to use gulp.src or any other method. You can start shell scripts, you can spawn servers, command livereloading, perform computations and evaluate conditions, etc. and, above all, you have a direct connection with the underling JavaScript application, as you can actually import its modules. In addition to this, I have a consistent interface in which I can define parameters and help texts, and that's definitely a plus for anyone who's looking at the project's tasks for the first time.