Yarn: Relationship to jspm

[jonaskello]

This project seems really promising!

From what I understand (which may not be correct), yarn aims to replace npm as a better alternative. I just wanted to check if there has been any thoughts about the aim of the yarn project in relation to jspm. For example, is the aim of the yarn project to cover also the cases that jspm does (eg. making packages available for loading directly in the browser without bundling)?

Currently I think many developers use both npm and jspm in the same project. In my experience, having to manage two package managers is sometimes a bit difficult. For me a dream scenario would be a merge between jspm and yarn so I only would have one package manager to manage :-).

[atrauzzi]

Would love to see if yarn and jspm have any opportunities together.

@guybedford

[julienvincent]

Also interested in this.

@alexisvincent

[ljharb]

It seems like this would be better accomplished by jspm building on top of yarn, instead of bloating yarn with support for a (minority) alternative package manager.

[alexisvincent]

@ljharb Building on top of yarn?

[ljharb]

@alexisvincent I'm responding to "Currently I think many developers use both npm and jspm in the same project." - perhaps jspm could use yarn to remove the need to use anything but jspm in their projects?

[alexisvincent]

Ok, I see what you mean. But I'm not sure there would be much utility in this other then a slight convenience since npm and jspm target different use cases, but maybe @guybedford has some ideas? . Something that could be interesting in a separate thought, would be leveraging yarns determinism (lock file) to aid in building a node loader for SystemJS.

[jonaskello]

The way I see it npm will forever be coupled to node so basically, by it's own will only ever be able to support server-side only development. Granted jspm is in minority compared to npm. However, JS is primarily a client-side technology, so the number of projects doing pure server-side development is also in minority. Thus I think a majority of the projects are using webpack, browserify etc. if they are using package management at all.

I would love to see yarn take a more holistic view on package management for the web, not only just for server-side development with node.

Jspm in itself may not be interesting but I think there is opportunity for yarn to look at ways to supporting SystemJS and maybe also SystemJS Builder, which is what jspm is using anyway. These parts are more aligned with how the web standards are supposed to work in the future and it would be nice if yarn could be a part of that future.

[ljharb]

@jonaskello i'm not sure what you mean; npm is absolutely for both serverside and clientside development and always has been. There's never been a need for alternatives to exist for the purposes of "clientside", and still isn't.

[jonaskello]

@ljharb Not sure what you mean either but maybe I am misinformed. Could you outline how you do client-side development by using npm alone (without webpack, browserify etc.)? Also if you have any pointer to npm documentation stating it's scope includes client-side development that would be helpful.

[ljharb]

Those are different tools that do different things. npm delivers the packages, browserify/webpack/etc do bundling, uglify does minification, etc. Having a build pipeline for frontend dev is nothing new, and "for frontend" has never required there be no pipeline. Here is an article on npm's own blog from almost 2 years ago that addresses this.

[jonaskello]

Yes, there are many tools. You can either see this as an advantage or a problem. My point is that the node package manager (npm) was initially developed for node, and node is by design a server-side technology. Moreover it was initially developed for commonjs which by-design is a server-side only module technology. So npm is not bad at all but it was initially designed for a different scenario than it now has to support. Client-side support has certainly been added and there is no lack of extra tools to do this, which again you can think is a good thing or bad thing. I myself think the amount of disparate tooling and configuration needed to get a client-side JS project going today is hurting JS adoption. For example, the fact that something like create-react-app is even needed is a manifestation of this.

Yarn on the other hand is a new project that has the possibility to take a holistic view on both server and client and include emerging web standards that were not available when npm started (such as <script module="...">). This it can reduce the need for extra tooling and possibly reduce JS fatigue. Jspm 0.17 for example works with both client-side and server-side without requiring any extra tooling.

[jonaskello]

Just to clarify, I'm not suggesting that yarn should support jspm. I'm suggesting that yarn should replace jspm. It can do this by adding support for installing modules so they can be directly loaded into the browser using a module loader. My suggestion would be that the supported module loader should be SystemJS (which is what jspm uses).

[ljharb]

Using SystemJS is a very very opinionated choice (tbh, as is choosing any module loader - but especially one that purports to implement a not-yet-finished module loader spec). I wouldn't think yarn is the best place to be that opinionated.

[jamiebuilds]

@guybedford if you want to sync up sometime about yarn and jspm let us know. I don't know that anything needs to happen. But it'd be nice to chat again sometime either way!

[atrauzzi]

@thejameskyle I agree, there's no guarantee, but it's certainly a conversation worth having. The biggest idea that comes to mind is simply not having to install two (three?!) separate package managers. Especially if one of them is powerful enough to leave me wanting that effectiveness across the board.

There may be other opportunities as well, but I trust you guys will cover it all quite quickly ;)

[guybedford]

From a comparison perspective the same points as for jspm and npm apply. jspm is attempting its own goals for module linking in the browser, and how that fully plays out is still yet to be determined. The strength of our tools comes from being able to try different things, and feeding that back into the knowledge of the community at large. This research value is certainly worth having separate projects and installs at least for the next couple of years.

@thejameskyle thanks and please do get in touch anytime, always happy to chat again as well.

[alexisvincent]

@guybedford Can you see any issues with using yarns lock file to generate a SystemJS config file, to resolve from node_modules?

[SerkanSipahi]

Can anyone explain shorty whats the main difference is between jspm and yarn? I see almost no differences. Im using jspm from beginning(started with systemjs, systemjs-builder and switch then to jspm) and im very happy with that ! All the other tools (webpack, browserify, etc) are to complicated!

yes sure, there is a spec but i cant wait for finishing! I love the module-loader (https://github.com/ModuleLoader/es-module-loader).

What i mean is, jspm do everything what you want as javascript developer for client and server side!

Sorry for my english :)

[alexisvincent]

ping @guybedford

[DaSchTour]

I'm really confused about some statements here. Using node and npm with CommonJS is also a very "opinionated choice". And still SystemJS is the best choice as it doesn't have problems with "transpiling" from CommonsJS to UMD or such crazy workflows. The point is that there is no package-manager (beside JSPM) that provides good handling for client-side module loading and bundling. I think we all struggle with the same issue. It needs a lot of work to build a working foundation for modern JavaScript app development and there is no satisfying solution. So the question shouldn't be if yarn kann be an alternative for JSPM but if yarn can improve client/frontend/browser module loading and bundling or will fail like npm and bower do.

[alexisvincent]

@DaSchTour well said.
I've been playing around with some ideas and I thought I'd leave them here for discussion.

Modern client side module loading and bundling has mostly been an after thought and it shows. Theres a lot of config and smart tooling required to get code running in the browser.

One of the main issues being indeterministic dependency trees. Since the latency cost of the browser <-> server is far to high to search for dependencies as is the NPM way, the browser needs to know beforehand how to resolve all files. Obviously this is not particularly easy with npm.

Enter JSPM. From what I understand of how it functions, JSPM performs two major roles. Firstly it provides deterministic installs, and secondly, it performs some package transformations to allow for loading via SystemJS.

Lets imagine the second issue didn't exist for a moment. Yarn for fills this first role. It provides deterministic dependency trees. Now, we could simply analyze the yarn lock file (might need a bit for then just this), and spit out a manifest (SystemJS config file) that informs the browser about where to find dependencies.

This is cool for a few reasons.

• We no longer need two package managers
• We no longer need two dependency install locations
• Simplified workflow

The step to generate a SystemJS config file doesn't need to be supported via yarn. But this would be awesome. A simple yarn browser-config or something similar could do it.

I have no idea to what degree JSPM modifies packages to work with SystemJS, but assuming this step isn't difficult, we could potentially get this working.

@guybedford I'd really love to hear how feasible you believe this to be.

[jonaskello]

IMO jspm is an great project that has done some ground-breaking work when it comes to installing modules so they could be directly loaded. I certainly hope it will continue to do so. So just to clarify, I did not mean that yarn should replace the research done in jspm. What would be awsome though is if the findings from the jspm project could fed back into yarn so it could support package installing for both client and server-side loading.

I think what @alexisvincent outlines could be a good way to do it. I'm not sure what transforms jspm applies to the packages either. I know that I have successfully loaded untransformed commonjs modules directly from node_modules with SystemJS. One thing jspm does is that it creates a separate .json file for each package it installs. SystemJS will look for these files if you set packageConfigPaths in it's config. They contain meta-info about the package, such as which is the main file and what format the package is in (commonjs, esm, amd etc.). In many cases SystemJS can auto-determine the format, but I had to specify it as cjs for loading of my commonjs package to work directly from node_modules. However I don't think these meta-files are necessary as the same info could be generated directly into the config.js file.

[alexisvincent]

@jonaskello I didn't want to dismiss JSPM. I'm greatly invested in the project and @guybedford has done a fantastic job creating a fantastic package manager. Especially considering npm. I'm just wanting to see if as you said "the findings from the jspm project could fed back into yarn so it could support package installing for both client and server-side loading". I think its healthy for any industry/sphere to have some competition. Apologies if I sounded dismissive.

[jonaskello]

@alexisvincent That was not directed at you but at my own earlier comment :-). Maybe we should start a new issue that is regarding adding support for SystemJS to yarn? That does not really concern jspm so the issue title may be confusing.

[alexisvincent]

@jonaskello Sure, sounds good :) Where would you like to see this issue go?

[jonaskello]

I made a new issue regarding SystemJS support here in the yarn repo. Closing this one in favor for that one.

[jonaskello]

There is now discussions on creating a POC for SystemJS integration here.

[alexisvincent]

Another project that might interest members of this thread is alexisvincent/systemjs-config-builder.