Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:59
    joeldenning commented #2148
  • 15:58
    joeldenning commented #2148
  • 09:46
    csr632 commented #2148
  • 09:45
    csr632 commented #2148
  • 04:59
    joeldenning commented #2148
  • 04:50
    joeldenning commented #2148
  • 04:49
    joeldenning commented #2148
  • 04:35
    joeldenning opened #2149
  • 04:33

    joeldenning on build

    Updating footprint script (compare)

  • 04:08

    joeldenning on build

    Self review (compare)

  • 04:06

    joeldenning on build

    Self review (compare)

  • 04:04

    joeldenning on build

    Self review (compare)

  • 03:58

    joeldenning on build

    Self review (compare)

  • 03:58

    joeldenning on build

    Self review (compare)

  • 03:56

    joeldenning on build

    Self review (compare)

  • 03:54

    joeldenning on build

    Review (compare)

  • 03:53

    joeldenning on build

    Self review (compare)

  • 03:52

    joeldenning on build

    Review (compare)

  • 03:50

    joeldenning on build

    Build Things Stuff and 4 more (compare)

  • Mar 28 16:09
    csr632 commented #2134
fredlllll
@fredlllll
is there a way to name an import?
fredlllll
@fredlllll
aparently the answer is to build threejs as systemjs module by changing the rollup configuration. similar for the loaders and controlers from the examples. change the import to just use "three" not the path to the js file. add three as external dependency in the rollup config, and then it properly builds those as system modules. oof i say
yuyic
@yuyic
Hi everyone, I tried to require("systemjs"); in node.js, but can not find module 'systemjs'...
yuyic
@yuyic
Module not found: Error: Can't resolve 'systemjs'
Guy Bedford
@guybedford
@yuyic SystemJS 2.0 doesn't yet support usage in Node.js
previously the project did support Node.js execution, but now that Node.js has full ES module support there isn't so much of a need for it
the main specifically throws like that so we can add this in future if users want it
if you're interested in working on this I'd be glad to advise
Paul Spencer
@pagameba
Hi, is it possible to pass authorization headers when requiring remote modules?
Khang Nguyen
@khangsfdc

@kensnyder

What is the recommended way to load a file that uses commonjs? For example the file https://unpkg.com/lodash.forown@4.4.0/index.js ends with module.exports = forOwn; and so I get a ReferenceError: module is not defined. Also, I don't see any babel transforms that will convert commonjs to System.register calls.

Using Rollup plugin (https://github.com/rollup/rollup-plugin-commonjs), it can be converted to ESM, which can then be converted to system register format

Guy Bedford
@guybedford
@pagameba with the fetch hook PR this would be possible. You can watch systemjs/systemjs#2058 to see when this lands.
SystemJS mostly tries to follow ES module semantics, which don't currently offer anyway to customize Authorization for fetching
I would love to push some spec work here for ES modules in browsers, basically a manifest that allows describing per module:
  • integrity
  • dependencies (for preloading)
  • authorization
  • cross-origin
  • etc anything else deemed useful
Everytime I meet people working on these standards I try to pitch this, but it's a hard sell
@khangsfdc there is also https://system-dev.jspm.io/lodash.forown@4.0.0/index.js which can be loaded directly with SystemJS
Joel Denning
@joeldenning
@khangsfdc commonjs modules are not supported in systemjs@>=2. You can convert them to global variables, AMD, UMD, or System.register format
Alternatively, you can use the transform hook to convert them inside the browser into one of those formats
Dmitry Kirilyuk
@Jokero
Hi guys. What is the current syntax for this? I don't want to use script tag for this map
SystemJS.config({
  map: {
    jquery: '//code.jquery.com/jquery-2.1.4.min.js'
  }
});
Shubham Kanodia
@pastelsky
Hello everyone. I was wondering if someone's managed to crack loading of webpack assets (with split chunks) using System.import

So far, I've switched the project being built by webpack to export systemjs –

 libraryTarget: 'system',

and in another (webpack-built) frontend, I'm able to do a System.import('http://path-to-system-exported-file.js') just fine.

However, a problem arises when I enable splitChunks in the former module.

Enabling splitChunks means that I can no longer load path-to-system-exported-file.js, but it needs to be preceded by the split chunks, but I'm not sure how to do that.
@guybedford Would you know if there's a way to do this?
Anthony Frehner
@frehner
though you may not be using single-spa, the 2 bullet points here probably still apply to your situation: https://single-spa.js.org/docs/faq/#code-splits
Nathan Smith
@nathasm
Hello all, I am given a minified systemjs bundle (other.min.js) built using an older version of systemjs (0.19) from another team. I also have access to their systemjs config file (other.config.js) I am currently trying to use karma to test code that imports files contained in this bundle. I'm using a karma-test-shim to read my systemjs, and then import their other.config.js. However when my tests run they are unable to request/fetch files that are part of other.min.js bundle.
If I go to my browsers karma instance, I can see in my devtools console SystemJS.bundles is defined with other.min.js and all the files that are contained within. So SystemJS seems to know that the bundles exist and which files are contained within.
Any ideas on how to get a setup like this to work? Or an example that comes close to what I'm trying to do?
madeofsun
@madeofsun

Hello, I have faced a problem with SystemJS. I have converted a commonJS library to System.register format with Rollup, since the library is pretty big and I want to use only parts of it as external dependency for a banch of others small libraries. All good, but one annoying thing is here.
Instead of

import Calendar from 'biglib/calendar';
import Button from 'bilib/button';

I have to use

import * as CalendarModule from 'biglib/calendar';
import * as ButtonModule from 'bilib/button';

const Calendar = CalendarModule.default.default.Calendar;
const Button = ButtonModule.default.default.Button;
OptimusGhandi
@OptimusGhandi_twitter
That is the result of ES6. The first syntax imports a special value “default” that you can export as “export default { foo: ‘bar’ }”. The second imports everything exported from the module under your chosen name. That’s not a bug, it’s as intended
madeofsun
@madeofsun

Actually, it seems like an esModule is wrapped inside another esModule, since there are 2 defaults, instead of 1

I have found one solution to fix it
The lib had aggregation files in common JS:

module.exports = require('./components/button/Button');

I changed them to es6 style and now the correct version of import works (without 2 defaults):

export * from './components/button/Button';

Are this statements semantically equivalent or not? Why does it make a double export with commonJS? May it be caused by @rollup/plugin-commonjs?

P.S. There was a mistake in my previous message. The correct version of import should be

import {Button} from 'bilib/button'; // instead of import Button from 'bilib/button';
k-j-kim
@k-j-kim
Hi all! Quick question:
How does registerRegistry get updated when a module is deleted from the registry via https://github.com/systemjs/systemjs/blob/master/docs/api.md#systemdeleteid---boolean?
Duarte Cunha Leão
@dcleao

Can SystemJS not load ES6 modules?

@MicahZoltu, @guybedford Was an issue created, in the end? I couldn't find one. I believe that this will be needed, even when all browsers support ES modules natively. SystemJS will still probably be the only solution to support bundling (through named registers, although not perfectly, as there is currently no way to inform of the files in a bundle beforehand, similar to RequireJS's bundles configuration) and that will interoperate with legacy code — for those (like me, or, better, my employer) that are still very much dependent on legacy code (RequireJS; globals).
Unfortunately, I don't think that this is possible without transpilation (which kind of defeats the original goal). If ES6 is loaded using dynamic import, then all dynamic imports in those modules would be directly handled by the native dynamic import and not by SystemJS's System.import. The same could be said for other features such as import.meta (which SystemJS provides a means to extend).
Does this even make sense? Could, ever, transpilation + eval be feasible and performant?
Thanks!

Duarte Cunha Leão
@dcleao

@guybedford in the meantime, I saw that you are pushing for the depcaches feature, which I think is great, btw. Do you think that bundling techniques which preserve the original modules unmerged (like what is possible by named System registers) will not be needed anymore when something like depcaches comes to exist?

What do you think of others which have questioned the feasibility to rely solely on HTTP/2 (e.g. https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/)? Or, do you tend more to the Snowpack view (as described in https://medium.com/@asyncmax/the-right-way-to-bundle-your-assets-for-faster-sites-over-http-2-437c37efe3ff ) ?

What about other tentative approaches like link rel modulepreload, HTTP/2 server push, Cache Digest for HTTP/2, Early hints ?

These are very messy times and circumstances we're in... I would very much appreciate your guidance on these matters.
Thanks!

Edd Neal
@eddneal

Hi all, I am having an issue using the named-register extra and was hoping somebody could help me out.

I am in the process of updating from v 0.19.5 to v 6.2.4 and the old implementation had a lot of modules generated with module ids via babel plugin and concatenated into a single file, and unfortunately I still need to support this if possible. These concatenated modules are then imported from standalone modules using relative paths and this is where I am having an issue.

The named-register extra works fine when resolving a concatenated module from a standalone using a bare style of import, but not when a relative path is used.

So this works

import module from “dir/moduleName.js”

While this doesnt

import module from "../../dir/moduleName.js".

Been digging into systemJSPrototype.resolve and can see that resolveIfNotPlainOrUrl generates the correct full path (including protocol) from parentUrl, but resolveImportMap returns true because of the condition|| resolvedOrPlain.indexOf(':') !== -1 && resolvedOrPlain;

Which means the catch in the named-register extra systemJSPrototype.resolve never looks in this.registerRegistry, and if it did, it would be using the id value for this which is the relative path.

So it appears this use case is not accounted for, and named registers can’t be imported with relative paths?

Any help with this would be greatly appreciated.

Guy Bedford
@guybedford
@dcleao there is still an issue at systemjs/systemjs#2013
@dcleao no, RollupJS is still needed, but the production graph dependencies can benefit from depcache for lazy loading
The issue with ES modules is that they cannot load System modules, which kind of defeats the point, unless we add some kind of magical support for this, but that would require import maps with data: URL support (data URL support is not currently a feature of import maps)
Guy Bedford
@guybedford

@eddneal yes this is a limitation with named register - the registry is based on full URLs, while the named registrations are unnormalized. If we had a requireJS style baseURL we could know that dir/moduleName.js is supposed to be represented as https://url.com/dir/moduleName.js but the current implementation does not make this assumption and just writes the name into the registry as System.set('dir/moduleName.js', ...) not System.set('https://url.com/dit/moduleName.js', ...). One approach to work around this problem is to define the named registrations as a custom URI scheme - System.register('app:dir/moduleName.js') This way the modules in the registries are URLs and should behave with all the expected normalizations.

The proper fix to this problem is thus to (1) carefully document and check the above workflow (this is definitely a catch for many users) or (2) seek to apply normalization to the named register names, as a breaking future change. As I say I wanted to avoid this for simplicity with the concept of named registration directly writing into the registry, but the practical workflows do fail on this.

Duarte Cunha Leão
@dcleao
@guybedford Thank you for your response. So, I take it that you don't "believe" in the future of (traditional) bundling — as in AMD or Webpack —, where (production) modules preserve their identities whilst being delivered in a single file? I think bundling is still useful and is orthogonal to the use of RollupJS for "identity erasure bundling". Isn't this the use case for the named registry extra? At least, it will be useful until depcache and other standards provide an effective alternative. I'd love to see how depcache performs compared to traditional bundling.
Guy Bedford
@guybedford
@dcleao 100%, to note dissolve module boundaries is to leave optimizations on the table
and production module boundaries make sense from a production graph perspective
so its about optimizing the graph for loading, instead of being the graph of development encapsulation
which are two completely separate things
Edd Neal
@eddneal
@guybedford Thanks a lot for the explanation, it is greatly appreciated. I have been able to get around the issue by using the absolute path as the moduleId and therefore writing the absolute path to the registry, which appears to solve my use case. I would be for the normalization of the named register names if this change you have described were ever to be considered. Thanks again.
Joshua Wilson
@jwilson8767
Any of you fine modern JS experts know of any good kitchen sink libraries that have evolved since the rise of ES6? I've been using lodash for collection iteration and a few random things (like _.partial()), but I also have a bunch of other little things I find myself re-implementing in every project I touch and I just wonder if someone has bothered to collect a bunch of those into a single codebase.
Arnaud GIBERT
@arnaudgibert

Hi guys! We are trying to jump from 0.21.6 to 6.1.0 on our angular app (8 until this week and 9 almost working ;) ) But we just can't figure out how we can elegantly use systemjs with our system.
We used it 2 ways:
SystemJS.set("@angular/core", SystemJS.newModule(AngularCore)) => for node_modules
SystemJS.import(url).then( COMPILE_WITH_ANGULAR_COMPILER) => for custom plugables modules

But now we change it to :
System.set('@angular/core', AngularCore)
and we get :

  • System.set is not supported by webpack.

We saw your link to systemjs-webpack-interop but we use angular wich doesn't let us mess with webpack.
Do you, by any chance, have any idea about how we can solve that problem ?

tymfear
@tymfear

Hi, everyone. Can't make SystemJs module work in a separate script
I have importmaps like

{
  "imports": {
       "sidebar": "some url"
    }
}

and when I'm trying to do this in separate script (which is build with webpack then)

singleSpa.registerApplication(
  'sidebar',
  function() {
    return System.import('sidebar');
  },
  function() {
    return true;
  }
);

it says sidebar is not defined (sidebar is declared in webpack as external)

What am I doing wrong? It works perfectly with inline script in html file, but I'd like to extract it

Geovanny Junio
@geovannyjs
Hi Guys! Is there some docs for migrating from 2.x to 6.x? I have a setup with typescript generating the bundle with named register that was working properly with 2.x, so I am trying to migrate to 6.x and fixed all the imports stuffs to work with 6.x but had no success. I always get the following error: Uncaught (in promise) TypeError: t[1] is not a function. at system.min.js:4
ǝᴉsɹnoɥʇ sɐuoɾ
@thorseye

Using SystemJS 6.x, I'm trying to write a hook to append .js (to mimic the defaultExtension: 'js'property in SystemJS 0.x).
The purpose is to be able to keep writing code like this in Typescript:

import { x } from './my/local/file/x';

instead of:

import { x } from './my/local/file/x.js';

I have the following code:

const endsWith = (str, suffix) => str.indexOf(suffix, str.length - suffix.length) !== -1;

        const origResolve = System.constructor.prototype.resolve
        System.constructor.prototype.resolve = function (moduleId, ...args) {
            console.log(moduleId, args);

            const lastSlash = moduleId.lastIndexOf('/');
            const lastDot = moduleId.lastIndexOf('.');
            const hasFileExtension = lastDot > lastSlash;

            const filename = hasFileExtension ? moduleId : `${moduleId}.js`;

            return origResolve.call(
                this,
                filename,
                ...args
            );
        };

This works, as long as I don't put anything in a systemjs-importmap.
I've tried too look in the documentation, but can't seem to find a way to lookup what's in the existing importmap - is there an easy way?
Or should I write my hook in a different way?

ǝᴉsɹnoɥʇ sɐuoɾ
@thorseye

I solved by overriding the fetch-hook instead. To do this you would need to set System.shouldFetch as so:

System.shouldFetch = () => true;

const endsWith = (str, suffix) => str.indexOf(suffix, str.length - suffix.length) !== -1;

const origFetch = System.constructor.prototype.fetch
System.constructor.prototype.fetch = function (url) {
    const lastSlash = url.lastIndexOf('/');
    const lastDot = url.lastIndexOf('.');
    const hasFileExtension = lastDot > lastSlash;

    url = hasFileExtension ? url : `${url}.js`;
    return origFetch.call(this, url);
};

Is this the preferred way to do this?

ǝᴉsɹnoɥʇ sɐuoɾ
@thorseye
I created a pull request with this, since I found it quite hard to read documentation about how this should be done:
systemjs/systemjs-examples#13