161–170 of 239 posts
Earlier quoted context omitted.
Do people typically prefer TypeScript over ES6?
Noone around me does. Typescript and JSX are the two ugliest tech to become fashionable recently. I suspect C#, or .NET developers find it familiar, and they've just joined the front end wagon.
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript tak…
Also, I'm sorry but you make some weird comparisons. ES6, Coffeescript, TypeScript and Python/Ruby are 4 completely different things. Not sure why you are trying to compare them and choose a winner.
> The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
Earlier quoted context omitted.
Apples to oranges. You can use TypeScript without ES* -> ES5/ES3 transpilation. The compilation process may not be as fast as not having one, but it will be similar in speed to running a few sed commands over your source code. GCC startup time is going to be faster than Node.JS startup time, but that's irrelevant. We don't need to restart the compiler on each iteration. You can just use an auto reloader for that. And…
> We don't need to restart the compiler on each iteration. You can just use an auto reloader for that. Interesting, I hadn't considered that. I've always just had a build script (usually in package.json), and run that when I change something (either with an inotifywait loop or manually). It does make sense that if you're instead keeping one long-running node.js process instead of spawning a new node.js instance every…
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi...
And of course you can read the source code for Webpack's typescript support.
Sidenote: although it's less popular, I highly recommend looking into Parcel Bundler, it's much nicer to use and has no configuration required. You can, for example, point it at an HTML file with a script tag pointing to a TypeScript entrypoint that includes NPM modules and it will handle compiling, bundling, minifying transparently. And it's relatively quick.
Since it seems the devs are here answering questions: Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? How will paths be translated on Windows? I’ve attempted something similar recently and had to do a fair amount of regex magic + using cygwins built in path translation utility to preprocess commands. Curious to see if there’s a…
> Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scri…
p.s. I love Yarn :)
Earlier quoted context omitted.
Because npm is a standard (default) package management tool that comes with node. After getting `package-lock.json` and `npm ci`, I would rather wonder why choose yarn instead of npm.
"npm ci" deletes node_modules directory every time. Try using that when you depend on some native modules. :(
Earlier quoted context omitted.
Funny how you say the two are completely unrelated and then go on to show how they are related with your personal experience.
While you're technically correct, this misses the value of static type checking vs type checking in tests. Tests must be written manually, must check every code path and must be updated whenever the underlying implementation changes, in order to achieve the results of static type checking. But types are declarative and will be checked automatically for every code path called.
Earlier quoted context omitted.
npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.
I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.
Yarn will actually do the merging automatically — if you have conflict markers in your lockfile, just running yarn will parse them along with the rest of the file and produce a new lockfile with the changes from both diffs (unless there's a genuine conflict).
I assume that this feature won't go away with the new lockfile format
Earlier quoted context omitted.
npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.
I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.
Earlier quoted context omitted.
Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity. It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.
How does an error code make it easier to look up an error? The workflow is either “get error, google it”, or “get errorcode google it”. In both cases the docs will be the top hit. If we where talking 20 years ago I might agree, but I really can’t see the argument with todays tooling.
Also many times the error message is interpolated with your specific details like
"Syntax error at line 123 in file /home/user/myfile , symbol X is not allowed here" this is a silly example but often enough when i google this errors I have to first strip out my data from them.