arcatek

10 ms·

61.
by arcatek 8y ago
The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)
62.
by arcatek 8y ago
> If you use either of these features your package.json will no longer work with NPM. Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In a
63.
by arcatek 8y ago
Note that this is mostly about the command line syntax, not so much the commands themselves which will be executed just like now. That being said, maybe we'll offer some builtin as well (possibly in a similar way to what CMake offers?[
64.
by arcatek 8y ago
> 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 ba
65.
by arcatek 8y ago
Most of those have been fixed a long time ago, but we simply don't have the resources to triage them. This effort we start is in no small part to decrease the number of issues that will be created by empowering the users to unblock the
66.
by arcatek 8y ago
We want the lockfile to be easy to review by humans. In our experience, JSON doesn't quite fit the bill once you reach a critical mass of data. Our lockfile format worked fine for the past three years (bar the unfortunate YAML incompat
67.
by arcatek 8y ago
We'll make sure to add a notice at runtime to make it clear (plus, a consequent diff at review). Also note that we recommend using `yarn policies set-version` to enforce the version of Yarn used by everyone in your team with very littl
68.
Yarn's Future – v2 and beyond(github.com)
380 points by arcatek 8y ago|232 comments
69.
by arcatek 8y ago
Worth noting that the principle of "a package can only access the dependencies it declared" is already something that we (Yarn) are pushing through Plug'n'Play. We're not focused on security (yet), but any help we c
70.
by arcatek 8y ago
I meant "at your own pace" as in "they let you decide how you want to learn it". Meaning that instead of following classes (which were quite basic anyway) I spent most of my time reading man pages and reading obscure for
71.
by arcatek 8y ago
Something interesting is that the way Epitech (and 42) work is completely different from what you would have in public schools (at least in France). For example, one key part for me was that the school allowed me to practically don't g
72.
by arcatek 8y ago
It doesn't have a lot of advantages right now. That said, it won't stay true forever. PnP is but the first step of a long-term goal I have. Check the Section 6.B from the whitepaper[1] for more details. [1] https://gith
73.
by arcatek 8y ago
Flow is already 100% compatible with PnP, through the use of the `module.resolver` configuration settings. We even saw some slight perf increases after switching in. I guess the same could be done for other tools: the .pnp.js file can be ea
74.
by arcatek 8y ago
Since the resolution is new, most of them requires plugins. I already wrote those for the most common projects: https://github.com/yarnpkg/pnp-sample-app/tree/master/script... They'll be published a
75.
by arcatek 8y ago
We'll see what the community response is, and once we're confident this is what everyone wants we'll merge it into master (PR is already up[1]). While there isn't an official build at the moment, the code PR includes a p
76.
by arcatek 8y ago
> what's being done to make this the default behavior in node and deprecate node_modules proper My hope is that PnP proves that this approach can work and raises the stakes for Node to implement APIs that would allow for a better in
77.
by arcatek 8y ago
> when the module you're looking isn't in the static resolutions table The fallback will kick in when the package that makes the request isn't in the static resolution table. Since those packages aren't part of the
78.
by arcatek 8y ago
The .pnp.js file can be checked-in, but needs the cache to work. Right now I'd advise not to check-it in. `yarn unplug` will eject a dependency from the cache and put it into the project folder. That's a quick and easy way to insp
79.
by arcatek 8y ago
I did work on the asmjs/wasm bindings for Yoga, Text-Buffer, and a few other projects, so I'm biased :) Anyway, regardless of my own long term feelings, rest assured that postinstall scripts will be supported as well as they are n
80.
by arcatek 8y ago
Yes, we only do a single stat in those cases (to check whether it's a directory or not).
81.
by arcatek 8y ago
Someone working on the wasm will likely be able to tell you more, but from what I understood dynamic linking is on the table[1]. I didn't quite say that it was ready yet , but rather that it was on the right path. [1] https:/&#x
82.
by arcatek 8y ago
I mentioned it in another answer, but we'll eject the packages that require postinstall scripts - so they will work as before, but will take extra time to be installed. As for wasm, I'm curious to hear what you think isn't go
83.
by arcatek 8y ago
It works in two steps: the first step resolve to "unqualified paths" (which are just the paths within the cache without the index.js/extensions resolution). This step is entirely static, no filesystem involved here. The secon
84.
by arcatek 8y ago
I think you're referring to the package-name-maps[1] proposal. We've been made aware of it during the middle of the development, and while we chose to continue using the static data tables approach, they aren't incompatible.
85.
by arcatek 8y ago
Postinstall scripts are the main issue, yep. Right now the current implementation doesn't do anything special with them, meaning that they are installed inside the cache (except when they're disabled altogether, which often works
86.
by arcatek 8y ago
Workspaces are working just fine: instead of creating the symlinks we simply register them into the static tables, and resolve them from their actual location on the disk. Nohoist was a bit of a hack from the beginning (precisely because th
87.
by arcatek 8y ago
I'm the author behind the proposal, feel free to ask me any question you might have! As a personal note, I'm super excited and so grateful to have had the chance to work on this project - node_modules have been a longstanding thor
88.
by arcatek 8y ago
I work on Yarn. The message you're quoting is from the npm CTO. We don't do yarn-specific changes. The main reason we're using a mirror is because it was massively faster than directly querying the npm registry when Yarn got
89.
by arcatek 8y ago
Yes, the gc isn't exposed yet, so neither JS nor wasm are notified when an object goes out of scope (which would allow to reclaim the memory on the wasm side). It's on the roadmap, so it should eventually come.
90.
by arcatek 9y ago
For the time being you should be able to install it using the `--devel` flag, but the PR to move it to stable is on its way :)

More ›