Comments (14)
I think: gyp is kind of garbage, but it's the best garbage we have and our ecosystem has standardised around it. It's already "official" so where it gets bundled doesn't really seem to matter since npm is bundled anyway. What should concern people is the maintenance of gyp and node-gyp and its viability as something that not many people care deeply enough about to keep updated. Really it's just something we keep on life support because we know it's important but don't have the drive to do anything better (mind you, there are some folks that seem to want to contribute more radical improvements, but it's such an important piece of software that shepherding major changes in is a huge undertaking in itself cause there's so so much potential for breakage!).
Aside from that, no strong opinions. If there's energy for something like this, maybe you should be considering alternatives that might offer better user experience and future proofing? Investing in getting ninja.js going (stalled, but we nearly got to releasing an alpha), or pulling in cmake.js (there seems to be a lot of interest in it in the ecosystem) might be worthwhile. But if you just want consistency then gyp+node-gyp is fine, it just needs maintenance and love all the way down and we around here are all that are doing that.
from build-toolchain-next.
The idea is not to wrap node-gyp. The API I'm thinking would me more high level to simplify the build process from a user perspective (and that could be reused by package managers to implement their build methods). The API would also provide any Node.js-specific flags and header paths that need to be used when building an addon, but how to use those flags and paths would be responsibility of the build toolchains (like cmake-js). Note that
this is an early proposal, nothing is defined yet.
from build-toolchain-next.
The API can even come before deprecating gyp, and we can use it on node-gyp
to both validate and remove the dependency surface on node-gyp
. If we are able to decouple node-gyp
from package managers, and decouple build configs from node-gyp
, swapping it for another toolchain will be straightforward (implementation wise), and providing two toolchains will be possible with less code duplication.
from build-toolchain-next.
Note that this is an early proposal, nothing is defined yet.
Roger. It's too abstract for me atm, but I'm interested (mainly as co-maintainer in the prebuild org) to see where it goes.
from build-toolchain-next.
W.r.t. API’s there was an old stalled out PR that tried to do away with node-gyp and provide API’s to invoke the compile and link steps: nodejs/node#7440
from build-toolchain-next.
fascinating, although I was thinking something more abstract than that: the API only provides the information needed to build addons and we leave the "invoke and link" to the packages. And if we decide to bundle anything we can use this API to implement whatever we provide.
from build-toolchain-next.
On the surface decoupling node-gyp from npm and packaging instead with Node.js sounds like a good first step. I'd be interested in what @rvagg thinks about that.
from build-toolchain-next.
@rvagg for context, the idea is to move node-gyp to Node.js as a first step into moving to something else (cmake-js or whatever we choose). By moving it to Node.js now we have more control over the deprecation process (instead of having npm and other package managers as the middle man). Short term this will allow us to experiment faster. Long term we can provide a more seamless migration experience for the ecosystem.
from build-toolchain-next.
pnpm depends on node-gyp:
https://github.com/pnpm/pnpm/blob/21cd0f260191729a71115e1ae16654d2b4faf32d/packages/pnpm/package.json#L18-L20
https://github.com/pnpm/pnpm/blob/21cd0f260191729a71115e1ae16654d2b4faf32d/packages/pnpm/package.json#L164-L171
I'm not sure about yarn, but it seems to require modules or users to install node-gyp themselves.
/cc @arcanis
from build-toolchain-next.
I'm not sure about yarn, but it seems to require modules or users to install node-gyp themselves.
Yarn 1 used whatever node-gyp is available (either explicitly, or by accident due to hoisting, or in magic locations), or transparently installs it as a global package if it isn't there to be found. It's not a good strategy, since it encourages packages to omit depending on node-gyp, thus bypassing the lockfile and making installs less predictable.
Modern releases now require packages depending on node-gyp to either list it in their dependencies, or to be installed in a project where node-gyp is explicitly declared as a dependency/devDependency of the top-level, thus guaranteeing that the version used is consistent now and in the future (using the wrong node-gyp version used to break installs which previously worked fine).
Having a native build mechanism tied to Node doesn't strike me as a bad idea, my main worry would be that unless given special consideration it'd prevent retroactively applying build pipeline improvements to older Node releases (vs a package, which can be upgraded as any other dependency). For instance, say you later want to provide a utility in this pipeline to easily build WASM modules, would only new Node releases be able to use it?
In my opinion it really depends how much you plan to maintain this build pipeline: if it frequently receives new features, then a separate package seem to make more sense. If it's expected to frequently receive breaking changes, then making it builtin would be safer. Or perhaps the best would be a mix of both, with a low-level Node API that would rarely change (similar to napi in idea) and a companion package whose interface would regularly improve and which could be used with any Node version supporting this low-level API.
from build-toolchain-next.
It's not a good strategy, since it encourages packages to omit depending on node-gyp, thus bypassing the lockfile and making installs less predictable.
It's not that clear-cut, from a wider perspective than Yarn. Omitting node-gyp
gives the user a choice (e.g. if you have Python 2 installed: use old node-gyp
, if Python 3 then latest). It saves bytes on disk as node-gyp
is a relatively big package (2 MB unpacked). If an addon ships prebuilt binaries, then node-gyp
is only a fallback for lesser-used platforms (for which the addon maintainer likely isn't giving guarantees or support) or an opt-in tool for wanting to build from source.
from build-toolchain-next.
Omitting altogether is far in the future, because today node-gyp is heavily dependent on the Node.js version it's shipped with (another reason to bundle node-gyp within Node.js and not npm).
from build-toolchain-next.
If the intent of bundling is to gradually replace node-gyp
, with a Node.js API that would wrap node-gyp
and eventually something else, how do we prevent that API from becoming the next node-gyp
or cmake-js
?
It has to deal with a lot of tedious details that aren't easily abstracted away.
from build-toolchain-next.
@vweevers good to know you are keeping an eye on it. It's important that we consider all of the aspects like prebuild etc.
from build-toolchain-next.
Related Issues (11)
- Investigate feasibility and challenges hybrid builds
- Forming a team to work on Future of build toolchains initiative HOT 20
- Should we remove support for building with MSVC? HOT 2
- Initiative needs a champion HOT 4
- The xPack toolchains, other development tools and xpm
- GN an Ninja platform support HOT 1
- Infrastructure plan HOT 1
- Devise a migration plan for native addons HOT 18
- Re-evaluate our approach to in-tree dependencies HOT 1
- What trade-offs are we willing to have with our next meta build system?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from build-toolchain-next.