Hello! 👋

I'm very excited about this project, but I have some questions on how it interacts with TypeScript. Specifically: how it interacts with typdefs from DefinitelyTyped.

Since DT typedefs are based on looking up the package name, are the /web_modules routes used by @pika/web incompatible with DT?:

// For this example, assume the typedef for Preact is coming from DT.
// If so, the typedef will only get applied if our import is from `preact`, 
// not from `/web_modules/preact.js`

// This will have typings
import { createElement, Component } from "preact";

// This will not
import { createElement, Component } from "/web_modules/preact.js";

Thanks for your time,
Alex

You criticize the size and # of dependencies required for a 'Hello World' JS app, whereas @pika/web requires 130 node modules altogether* and weights whooping 1.2 MB minified. So please start with yourself, give a good example and loose your weight, or better eat your own dog food and provide a single JS file to include in our projects.

EDIT: Now you cannot transform @pika/web using @pika/web, because there is no "module" entrypoint in package.json.

* Here is the list of @pika/web (sub)dependencies and their sizes in bytes:

"dependencySizes":[{"name":"@pika/web","approximateSize":6374},{"name":"chalk","approximateSize":6459},{"name":"rimraf","approximateSize":5094},{"name":"ora","approximateSize":4144},{"name":"yargs-parser","approximateSize":15274},{"name":"rollup","approximateSize":667100},{"name":"rollup-plugin-node-resolve","approximateSize":6142},{"name":"rollup-plugin-commonjs","approximateSize":18631},{"name":"rollup-plugin-terser","approximateSize":1406},{"name":"rollup-plugin-replace","approximateSize":1710},{"name":"rollup-plugin-json","approximateSize":636},{"name":"rollup-pluginutils","approximateSize":6546},{"name":"acorn","approximateSize":115095},{"name":"webpack","approximateSize":487},{"name":"estree-walker","approximateSize":872},{"name":"resolve","approximateSize":11290},{"name":"magic-string","approximateSize":25418},{"name":"sourcemap-codec","approximateSize":2299},{"name":"builtin-modules","approximateSize":248},{"name":"glob","approximateSize":21474},{"name":"is-module","approximateSize":398},{"name":"escape-string-regexp","approximateSize":195},{"name":"ansi-styles","approximateSize":2659},{"name":"supports-color","approximateSize":50},{"name":"cli-cursor","approximateSize":394},{"name":"cli-spinners","approximateSize":7137},{"name":"log-symbols","approximateSize":90},{"name":"strip-ansi","approximateSize":189},{"name":"wcwidth","approximateSize":2886},{"name":"camelcase","approximateSize":1548},{"name":"decamelize","approximateSize":255},{"name":"@babel/code-frame","approximateSize":3829},{"name":"jest-worker","approximateSize":19785},{"name":"serialize-javascript","approximateSize":2066},{"name":"inherits","approximateSize":403},{"name":"minimatch","approximateSize":10293},{"name":"path-is-absolute","approximateSize":381},{"name":"fs.realpath","approximateSize":4761},{"name":"once","approximateSize":729},{"name":"micromatch","approximateSize":13794},{"name":"inflight","approximateSize":578},{"name":"color-convert","approximateSize":12630},{"name":"restore-cursor","approximateSize":175},{"name":"ansi-regex","approximateSize":322},{"name":"defaults","approximateSize":210},{"name":"@babel/highlight","approximateSize":2438},{"name":"terser","approximateSize":336616},{"name":"to-regex","approximateSize":1930},{"name":"extend-shallow","approximateSize":998},{"name":"wrappy","approximateSize":467},{"name":"brace-expansion","approximateSize":2746},{"name":"onetime","approximateSize":534},{"name":"signal-exit","approximateSize":2440},{"name":"clone","approximateSize":2063},{"name":"braces","approximateSize":16668},{"name":"js-tokens","approximateSize":1103},{"name":"esutils","approximateSize":29308},{"name":"kind-of","approximateSize":2577},{"name":"regex-not","approximateSize":697},{"name":"array-unique","approximateSize":466},{"name":"snapdragon","approximateSize":12651},{"name":"define-property","approximateSize":1925},{"name":"fragment-cache","approximateSize":525},{"name":"merge-stream","approximateSize":690},{"name":"safe-regex","approximateSize":719},{"name":"nanomatch","approximateSize":20950},{"name":"arr-diff","approximateSize":390},{"name":"object.pick","approximateSize":318},{"name":"extglob","approximateSize":11148},{"name":"concat-map","approximateSize":243},{"name":"balanced-match","approximateSize":758},{"name":"color-name","approximateSize":3424},{"name":"mimic-fn","approximateSize":221},{"name":"path-parse","approximateSize":1681},{"name":"assign-symbols","approximateSize":585},{"name":"isobject","approximateSize":107},{"name":"is-extendable","approximateSize":108},{"name":"is-plain-object","approximateSize":351},{"name":"split-string","approximateSize":2069},{"name":"map-cache","approximateSize":496},{"name":"ret","approximateSize":6078},{"name":"arr-flatten","approximateSize":196},{"name":"fill-range","approximateSize":3577},{"name":"repeat-element","approximateSize":110},{"name":"snapdragon-node","approximateSize":4857},{"name":"base","approximateSize":4426},{"name":"readable-stream","approximateSize":32703},{"name":"is-descriptor","approximateSize":1893},{"name":"is-number","approximateSize":1507},{"name":"debug","approximateSize":4039},{"name":"repeat-string","approximateSize":409},{"name":"component-emitter","approximateSize":1494},{"name":"use","approximateSize":1312},{"name":"expand-brackets","approximateSize":6498},{"name":"to-regex-range","approximateSize":4178},{"name":"snapdragon-util","approximateSize":9055},{"name":"cache-base","approximateSize":1524},{"name":"mixin-deep","approximateSize":608},{"name":"pascalcase","approximateSize":352},{"name":"class-utils","approximateSize":3418},{"name":"source-map","approximateSize":39499},{"name":"source-map-resolve","approximateSize":5465},{"name":"is-windows","approximateSize":481},{"name":"get-value","approximateSize":542},{"name":"to-object-path","approximateSize":1676},{"name":"arr-union","approximateSize":344},{"name":"collection-visit","approximateSize":399},{"name":"union-value","approximateSize":1507},{"name":"unset-value","approximateSize":1050},{"name":"has-value","approximateSize":194},{"name":"set-value","approximateSize":977},{"name":"for-in","approximateSize":121},{"name":"is-accessor-descriptor","approximateSize":2001},{"name":"is-data-descriptor","approximateSize":1791},{"name":"static-extend","approximateSize":1141},{"name":"source-map-url","approximateSize":728},{"name":"resolve-url","approximateSize":668},{"name":"is-buffer","approximateSize":347},{"name":"core-util-is","approximateSize":1400},{"name":"process-nextick-args","approximateSize":746},{"name":"safe-buffer","approximateSize":1082},{"name":"object-visit","approximateSize":523},{"name":"isarray","approximateSize":113},{"name":"map-visit","approximateSize":558},{"name":"has-values","approximateSize":1963},{"name":"object-copy","approximateSize":2999},{"name":"ms","approximateSize":1389},{"name":"posix-character-classes","approximateSize":307},{"name":"util-deprecate","approximateSize":455},{"name":"copy-descriptor","approximateSize":738}]}

When jail is enabled for rollup-plugin-node-resolve, @pika/web can't resolve modules

looks like node_modules for projects on glitch is stored in a different place.

When jail is enabled

https://glitch.com/edit/#!/pika-web-jail

When jail is disabled

https://glitch.com/edit/#!/pika-web-no-jail

Maybe add a flag to disable jail?

Would it be possible (or preferable) to automatically prepend "/web_modules" onto each import statement?

After reading #68 it got me thinking about cache busting. I don't know if HTTP/2 servers make it a non-issue, but I'm curious what your thoughts are on cache busting.

ES modules do not seem to address this issue but it seems like a significant issue. Without it you cannot reliably instruct browsers to cache certain files or files within folders.

When looking at https://www.pika.dev/packages/async#releases I see that packages are broken out by major version on your CDN but no more granular. If someone visits my website and it references thing/v3 (which is really [email protected]) and then later comes back to my website and a new feature has been added to [email protected] that I now use in my website, the cached version of thing/v3 in the persons browser will be missing the new feature and my website will error. I mention your CDN as an example of this general problem.

Libraries like require.js support cache busting and make it possible to aggressively cache resources without worrying. Build tools, whatever other headaches they cause, also make cache busting/versioning possible. Having the considered all of this it seems like something closer to a build tool but easier to use that would build out versioned directories into the web_modules folder and re-write import statements to match those versions would be the ideal.

I'm trying to use pika/@web to install unistore with Preact integration.

The non-pika way of importing would be:

// The store:
import createStore from 'unistore'

// Preact integration
import { Provider, connect } from 'unistore/preact'

// React integration
import { Provider, connect } from 'unistore/react'

But in pika, I don't see how to import unistore/preact.

unistore's package.json only refers to one module – dist/unistore.es.js – which doesn't import or export the preact module, full/preact.es.js.

I tried forking unistore, and edited its package.json in a few ways, npm installing it each time:

1 -- main, module, +extra modules

Here I added a modules key, with the extra files I wanted exposed:

{
  "main": "dist/unistore.js",
  "module": "dist/unistore.es.js",
  "modules": [
    "full/preact.es.js",
    "full/react.es.js"
  ],

But npm install deleted the "modules" key when it outputs a built package into node_modules.

2 -- main, module, +overlapping modules

Here I added a modules key, with the extra files I wanted exposed, plus the existing module already mentioned in the module key:

  "main": "dist/unistore.js",
  "module": "dist/unistore.es.js",
  "modules": [
    "dist/unistore.es.js",
    "full/preact.es.js",
    "full/react.es.js"
  ],

But npm install deleted the "modules" key when it outputs a built package into node_modules.

2 -- main, -module, +overlapping modules

Here I eschewed module in favour of modules key, with the extra files I wanted exposed:

  "main": "dist/unistore.js",
  "modules": [
    "dist/unistore.es.js",
    "full/preact.es.js",
    "full/react.es.js"
  ],

But npm install deleted the "modules" key when it outputs a built package into node_modules.

Conclusion

modules key as described in defense-of-dot-js proposal is not supported by npm.

I don't think there's anything I can change in package.json to expose these extra modules.

Is there any trick in pika to make it work? I can use whitelist to make pika look inside unistore/full folder, but pika will not do anything with the files in that folder unless it sees a package.json in there.

What's the most appropriate fix, and where's the most appropriate place to fix it? Does the source of unistore need changing?

Just a question - I used to create and use many packages with single ‘main’ entry but usable both in browser/node. Now due to this transition to esm we have to generate noise in package.json / dist folder. I thought pika provides graceful solution for web-modules - taking cjs (as I was doing) and compiling that to esm on install, (instead of forcing whole npm to change). That’s obvious there’s a lot of browser legacy cjs modules that aren’t going to transition to esm, like Buffer, tape etc.
Just curious - what’s the strong reason against taking ‘main’ cjs module entry?
Thanks!

First off, I want to give you guys props for this awesome project. Great Work 🎉 🎉

The more I use @pika-web, I feel like I should be able to skip NPM install step altogether.

Why would you want to do that?

This is why:

I am meaning to write full RFC on this, but wanted to throw quick thought to get some feedback.

Oh BTW, I did some exploration on this in #33

Can Pika CDN query a subfolder? e.g. how to use preact/hooks?

Expanding on the above, what's the recommended method for library creators?

import pkg from 'pkg'; // ES5
import pkg from 'pkg/modern'; // ES2019+

Should ES5 be the default (no transpiling node_modules), and allow users to opt-in to modern syntax by specifying the subfolder in the path (with its own package.json) that they can transpile themselves, rather than the other way around?

Before anything else, I just want to give you guys some props for this awesome project. Grat work! 🎉

Now over to my question. I was just wondering if there is any particular reason why pika ignores devDependences by default (unless webDependenceies is set in package.json). Am I missing something?

What if @pika/web could scan your project for root-level ESM imports, and automatically make them available?

The main benefit of this plan would be that you could skip white-listing modules and sub-modules in larger projects, and still get an optimally small web_modules directory.

For example, to more efficiently use styled-icons, I'm currently whitelisting individual icons like "styled-icons/fa-solid/Clipboard" and then importing those directly.

One way it could work is, if you have import preact from 'preact' inside "public/main.js", then it would see that you depend on the 'preact' module and it would export that. Similarly, if you have import {html} from 'htm/preact' then it would know it needs to export "htm/preact.js".

However, that has the flaw of the code not really being usable from the browser until the module paths are changed, since they would be using prefix-less names that (I'm assuming) assume the current directory, which wouldn't be the case.

An alternative solution is that user code has to always prefix paths with "/web_modules/" so that it will be correct after @pika/web exports the modules to that directory. This would also let @pika/web scan them, filter only ones that have this prefix, and remove the prefix to determine the actual package name.

@FredKSchott what do you think?

TLDR: This is a feature request to manage common js dependencies as well as es6 module dependencies.

Details:
If my dependencies includes a common js project, try converting it to es6 modules via https://github.com/rollup/rollup-plugin-commonjs (which is already in pika/web's package.json devDependencies).

It would be fine to limit this to explicit @pika/web.webDependencies rather than all of my package.json dependencies.

Congrats on the Pika CDN launch!

I noticed that you're using the Google Storage API under the hood, with URLs like https://cdn.pika.dev/workbox-window/v4 redirecting to https://storage.googleapis.com/pika-web-packages-01/workbox-window/4.3.1/dist-es2019/workbox-window.min.js

We (the Workbox team) use the Google Storage API in a similar manner, but I thought it was worth pointing out that this is actually a bit slower, and likely more expensive than using a "real" CDN solution. My understanding is that you end up charged for a call to the Google Storage API each time one of those URLs are requested, and you can end up incurring a decent amount of usage charges when what you expect is static hosting.

We've had a longstanding goal to move to a real CDN, perhaps along the lines of the instructions at https://cloud.google.com/load-balancing/docs/https/adding-a-backend-bucket-to-content-based-load-balancing, but haven't yet found the time to do it.

I figured I'd at least mention it to your team since to the uninitiated, storage.googleapis.com kinda-sorta looks acts like a static CDN. (Though the "googleapis" bit is a giveaway.)

as you see, thansk

Would it be possible to let pika default to using the main module in a package?

I just published a really dumb copy of the events module because the maintainers are busy and I wanted a module entry in the package.json. It wouldn't work for everything, but when it works it works.

I tried using pika/web with a simple React project and was confused when nothing happened. Only after adding preact as a dependency was the wed_modules folder created.

My package.json has this right now:

  "scripts": {
    "prepare": "pika-web --dest public/web_modules/"
  },

This is because I have my deployable code all under ./public/ so that I don't have to worry about having public files next to files like package.json, node_modules, etc. that are not intended to be deployed.

For this reason, it seems like it might be worth considering changing the default to this.

My goal is ultimately to get React-based libraries working with a command-line Pika setup, which installs modules locally into ./web_modules/ [1].

An example of this would be react-router-dom or styled-components, both of which depend on the 'react' package, and probably a lot of libraries that start with 'react-'.

This morning I just learned about these libraries that exist to make React compatible with Pika and/or ESM:

• https://www.npmjs.com/package/@pika/react
• https://www.npmjs.com/package/@pika/react-dom
• https://github.com/lukejacksonn/es-react

How can these be used to create web modules for libraries that depend on React?

More specifically, if a package such as styled-components is actually doing import React from 'react', wouldn't I have to modify the package locally to refer either to import React from '@pika/react' or import React from 'es-react'?

And wouldn't I need to do this for every package that depends on React? I think I counted about 15 in my client project.

[1] Actually --dest ./public/web_modules/ for what it's worth, since I want to just rsync all of ./public instead of having any public files side by side with package.json, node_modules etc. The former being the convention in Pika's examples confuses me since the latter seems like a better practice.

Howdy from Changelog! 👋

We'd love to have you on JS Party sometime soon. Who would be best person to join us to talk about Pika and all the cool stuff y'all are up to?

(Please email [email protected] to coordinate, if interested.)

Looking forward to it! 💚

First of all, awesome work. I love the idea!

Would you consider adding a --dest CLI option in order to define an output folder? While working with it I found I work in my projects with a src folder, so when importing without bundlers and transpilers, the fact that the web_modules is in the root made me to move manually the web_modules inside the src folder in order to ESM imports to work accordingly.

My src/app.js (loaded from an src/index.html) looks like that.

import htm from './web_modules/htm.js'
import {h, render} from './web_modules/preact.js'

Even If we want to perform the pika-web on the bundle process, if the site is static, sometimes we move the src to a public folder and I would like to to the pika-web directly pointing to a dest folder instead having to move manually.

If that do so I would love to work on it (any indication would be appreciated in order to optimize the process to get it merged ;)) and also I will like to know if the web_modules folder is a must or the dest folder would be completely customizable.

Thanks!

I am creating a webapp using pika. I don't understand how to generate source maps so that i can debug my appication (not dependencies)

✖ dependency "react" has no ES "module" entrypoint.
Its fixable?

Just followed the readme, got

$ npx @pika/web
npx: installed 75 in 9.201s
- @pika/web installing...
Error: You must supply options.input to rollup
    at Promise.all.then (C:\Users\dfcre\AppData\Roaming\npm-cache\_npx\6000\node_modules\@pika\web\node_modules\rollup\dist\rollup.js:16590:23)
    at processTicksAndRejections (internal/process/next_tick.js:81:5)
    at process.runNextTicks [as _tickCallback] (internal/process/next_tick.js:51:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:865:11)
    at findNodeScript.then.existing (C:\Program Files\nodejs\node_modules\npm\node_modules\libnpx\index.js:268:14)

In a way I imagined pika to be a package installer, alternative to npm, that puts any npm package compiled to ES module into /web_modules folder.

Just curious - what's the reasoning for making pika a local package installer npx @pika/web instead of global cli tool pika?

Carried over from polymer/pwa-starter-kit: Polymer/pwa-starter-kit#339
Relevant branch for viewing package.json versions: https://github.com/krumIO/pwa-starter-kit/tree/template-pika-web

Steps to reproduce:

1. Clone the repo/branch git clone -b template-pika-web https://github.com/krumIO/pwa-starter-kit.git
2. run npm install
3. run + observe npm run build

When running npm run build we do see some warning flags thrown, but looking at these in action may provide good feedback for both Lit and Pika:

C:\scrubbed\pwa-starter-kit [pika-web +0 ~1 -0 !]> npm run build

> [email protected] build scrubbed\pwa-starter-kit
> polymer build --auto-base-path && gulp prpl-server

info:   Clearing build\ directory...


    window.customElements.define(tagName, clazz);
                                 ~~~~~~~

file:///scrubbed/pwa-starter-kit/web_modules/lit-element.js(1985,34) warning [cant-determine-element-tagname] - Unable to evaluate this expression down to a definitive string tagname.


            window.customElements.define(tagName, clazz);
                                         ~~~~~~~

file:///scrubbed/pwa-starter-kit/web_modules/lit-element.js(2001,42) warning [cant-determine-element-tagname] - Unable to evaluate this expression down to a definitive string tagname.


const connect = (store) => (baseElement) => class extends baseElement {
                                                          ~~~~~~~~~~~

file:///scrubbed/pwa-starter-kit/web_modules/pwa-helpers.js(25,59) warning [could-not-resolve-reference] - Could not resolve reference to class
info:   (esm-bundled) Building...
info:   (es6-bundled) Building...
info:   (es5-bundled) Building...
info:   (es5-bundled) Build complete!
info:   (esm-bundled) Build complete!
info:   (es6-bundled) Build complete!
[17:56:32] Using gulpfile C:\scrubbed\pwa-starter-kit\gulpfile.js
[17:56:32] Starting 'prpl-server'...
[17:56:32] Starting 'prpl-server:clean'...
[17:56:32] Finished 'prpl-server:clean' after 27 ms
[17:56:32] Starting 'prpl-server:build'...
[17:56:33] Finished 'prpl-server:build' after 307 ms
[17:56:33] Finished 'prpl-server' after 340 ms
C:\scrubbed\pwa-starter-kit [pika-web +0 ~1 -0 !]> npm run serve

> [email protected] serve C:\scrubbed\pwa-starter-kit
> prpl-server --root server/build

Loading config from "server\build\polymer.json".
Serving files from "C:\scrubbed\pwa-starter-kit\server\build".
Detected push manifest "esm-bundled\push-manifest.json".
Detected push manifest "es6-bundled\push-manifest.json".
Detected push manifest "es5-bundled\push-manifest.json".
Registered entrypoint "esm-bundled/index.html" with capabilities [es2015,modules].
Registered entrypoint "es6-bundled/index.html" with capabilities [es2015].
Registered entrypoint "es5-bundled/index.html" with capabilities [].

prpl-server listening
http://127.0.0.1:8080

In a project with mobx, when running pika the process fails with the following stack:

SyntaxError: Unexpected token (4374:56) in ./node_modules/mobx/lib/mobx.module.js
    at Object.pp$4.raise (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2844:13)
    at Object.pp.unexpected (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:690:8)
    at Object.pp.expect (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:684:26)
    at Object.pp$3.parseExprList (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2734:14)
    at Object.pp$3.parseSubscript (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2163:25)
    at Object.pp$3.parseSubscripts (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2143:26)
    at Object.pp$3.parseExprSubscripts (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2129:21)
    at Object.pp$3.parseMaybeUnary (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2103:17)
    at Object.pp$3.parseExprOps (~/.npm/_npx/31271/lib/node_modules/@pika/web/node_modules/acorn/dist/acorn.js:2045:19)

TLDR: This issue is for an option to not produce source maps.

I'm using pika/web for three.js & it's orbit controls:

    "@pika/web": {
        "webDependencies": [
            "three",
            "three/examples/jsm/controls/OrbitControls.js"
        ]
    },

This also produces source map files which are huge and I don't need:

web_modules/
drwxr-xr-x@ 3 owen  staff    96B Jun 15 13:43 three/
-rw-r--r--@ 1 owen  staff   562K Jun 15 12:50 three.js
-rw-r--r--@ 1 owen  staff   1.8M Jun 15 12:50 three.js.map

web_modules/three/examples/jsm/controls:
-rw-r--r--@ 1 owen  staff    10K Jun 15 12:50 OrbitControls.js
-rw-r--r--@ 1 owen  staff    38K Jun 15 12:50 OrbitControls.js.map

I think this comes from the tracer rollup plugin? I'd like an option to not produce source maps.

Will it work with .vue files ?
Are there any examples for such a setup ?

Any option to jave output files as .mjs instead of .js?

I'm trying your tool and running npx @pika/web does not produce any web_modules directory.
The guess is the fact it's related to the way I need to call the import when it's not a module
My initial imports look like import Map from 'ol/Map.js';

You can find a repository to try out the sample I'm using at the following repository https://github.com/ThomasG77/pika-web-ol as it can be related to my code and not your tool.

Was the expectation of the --optimize CLI option, to bundle each package into a single minified ESM JavaScript file?

How can one launch a service, specially a CDN without IPv6 in 2019 is beyond me.

I can read that you support CommonJS modules, but what about AMD / RequireJS? Could you transform them as well? Example: knockout-jqautocomplete.

Just spent ~30 mins trying to get a console.log() working and I've only got syntax errors.

Could we add a simple example that isn't tied to a framework?

Maybe something that import Slugy - https://www.npmjs.com/package/slugy - and uses it to slug a sentence and then log it?

The concept is nice! I'm curious, what won't work. F.e., we're running a project with X and Y Webpack or Babel plugins, will it just work?

I'm a total newb at @pika/web so this is probably a dumb one, but I installed it:

yarn add --dev @pika/web

and ran it on my project:

npx @pika/web

and I get these two errors, and it never finishes (the spinner just keeps spinning):

% npx @pika/web
npx: installed 75 in 8.243s
⠋ @pika/web installing... { Error: Cannot find module 'rxjs-compat'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/mnt/c/dss/Product/Horizon/WebProjects/horizon-project/horizon/node_modules/rxjs/Rx.js:6:10)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3) code: 'MODULE_NOT_FOUND' }
⠏ @pika/web installing... @types/file-saver, @types/js-yaml, babel-jest, crypto-random-string, file-saver, firebase, firebaseui, jest, js-yaml, lodash, reflect-metadata, register-service-worker, v-tooltip, vue, vue-class-component, vue-router, vuejs-logger, vuetify, vuetify-confirm, vuetify-toast-snackbar, vuex, vuex-module-decoratorsError: Unexpected character '@' (Note that you need plugins to import files that are not JavaScript)
    at error (/home/garyo/.npm/_npx/9306/lib/node_modules/@pika/web/node_modules/rollup/dist/rollup.js:9365:30)
    at Module.error (/home/garyo/.npm/_npx/9306/lib/node_modules/@pika/web/node_modules/rollup/dist/rollup.js:13272:9)
    at tryParse (/home/garyo/.npm/_npx/9306/lib/node_modules/@pika/web/node_modules/rollup/dist/rollup.js:13187:16)
    at Module.setSource (/home/garyo/.npm/_npx/9306/lib/node_modules/@pika/web/node_modules/rollup/dist/rollup.js:13498:33)
⠇ @pika/web installing... @types/file-saver, @types/js-yaml, babel-jest, crypto-random-string, file-saver, firebase, firebaseui, jest, js-yaml, lodash, reflect-metadata, register-service-worker, v-tooltip, vue, vue-class-component, vue-router, vuejs-logger, vuetify, vuetify-confirm, vuetify-toast-snackbar, vuex, vuex-module-decorators^C

Any idea what I need to do to fix this? As far as I know all those modules are Javascript or typescript.

It would be helpful to have a React + Styled Components build example.

Thank you.

Is it possible to set the --dest option from within package.json#@pika/web similar to this:

  "@pika/web": {
    "dest": "htdocs/web_modules"
  },

What difference between @pika/web and systemjs? Does @pika/web support IE 11?

I am opening this issue for discussing ways to overcome or workaround IE's (lack of) ES6 support.

FYI: https://caniuse.com/#feat=es6

Consider the case of @apollo-elements/lit-apollo:

{
  "name": "@apollo-elements/lit-apollo",
  "version": "1.1.0",
  "module": "index.js",
  "dependencies": {
    "@apollo-elements/mixins": "^1.1.0"
  },
  "peerDependencies": {
    "lit-element": "^2.0.1",
    "lit-html": "^1.0.0"
  }
}

@apollo-elements/lit-apollo relies on @apollo-elements/lib which in turn relies on graphql-tag which has a peerDependency to graphql

pikawebification produces:

npx @pika/web                                                         24.8s
npx: installed 75 in 3.075s
⠼ @pika/web installing... @apollo-elements/lit-apollo
✖ 'lit-html' is imported by 'node_modules/@apollo-elements/lit-apollo/index.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'lit-element' is imported by 'node_modules/@apollo-elements/lit-apollo/index.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'lit-element' is imported by 'node_modules/@apollo-elements/lit-apollo/apollo-element.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'graphql/language/visitor' is imported by 'node_modules/apollo-client/bundle.esm.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'graphql/language/visitor' is imported by 'node_modules/apollo-utilities/lib/bundle.esm.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'graphql/language/parser' is imported by 'node_modules/graphql-tag/src/index.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'graphql/language/parser' is imported by 'commonjs-external-graphql/language/parser', but could not be resolved.
  Make sure that the file or package exists on disk.
✖ 'graphql/language/printer' is imported by 'node_modules/apollo-link/lib/bundle.esm.js', but could not be resolved.
  Make sure that the file or package exists on disk.
✔ @pika/web installed: @apollo-elements/lit-apollo. [1.50s]
⚠ Finished with warnings.

Perhaps pika/web should install those peerDeps?

Referencing: https://spectrum.chat/pika/pika-web/module-resolution-in-lerna-monorepos~c37f7bd6-0740-4b73-a634-613faf2a7bee

We would like to add additional resolution logic to support the case referenced in the conversation above. This would allow for resolution of hoisted modules in this case, but is also needed for parity with npm module resolution behavior. Consideration also needs to be made for whitelisting, we certainly don't want to pull modules from parent folders simply because they exist in /node_modules/.

@FredKSchott I have this earmarked for dev work on 5/17.

Running npx @pika/web with this package.json never finishes:

{
  "name": "podcrypt",
  "version": "0.0.0",
  "description": "Progressive Web DApp for podcasts",
  "engines": {
    "node": "10.7.0"
  },
  "scripts": {
    "start": "zwitterion",
    "build": "zwitterion --build-static --exclude node_modules --include functional-element,redux/es"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/lastmjs/podcrypt.git"
  },
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/lastmjs/podcrypt/issues"
  },
  "homepage": "https://github.com/lastmjs/podcrypt#readme",
  "contributors": [
    "Jordan Last <[email protected]>"
  ],
  "devDependencies": {
    "@pika/web": "^0.2.0",
    "jsverify-es-module": "0.0.2",
    "zwitterion": "0.28.1"
  },
  "dependencies": {
    "functional-element": "0.0.12",
    "idb-keyval": "3.1.0",
    "redux": "4.0.1",
    "rss-parser": "3.6.2",
    "web3": "1.0.0-beta.47",
    "web3-providers-es-module": "0.0.0"
  }
}

When specifying a whitelist of webDependencies, it would be nice if the list could be inferred somehow from imports in local project source files. For one case that I am working on, I want to specify specific files in the whitelist, but there could be almost a hundred distinct modules that need to be specified.

https://pika-web-example-preact-htm.glitch.me/ force-reload:

.../user-avatar/... is served from AWS 🐌 and Initial connection/SSL takes half a second 🐌

TBH I'm not sure if the request is just unlucky (e.g. hits Chrome's open connection limit) or actually slow due to AWS.

In any case, the page load time is ~2s (Tokyo), which doesn't really help sell the whole pika idea...

Hello, first of all, thanks for this project! It's cool to see more work being done in the area of ES Modules and bundlers!

I searched for a package today that didn't fulfill the necessary requirements for inclusion in the Pika CDN (search link), and got a partially-helpful error message:

This is a good start! But it would be nice for package authors and other open source users to have a link to a minimal, best-practices guide for how to update packages to support the necessary requirements.

I've since opened miracle2k/react-arrow#6 to update the field in package.json, but am uncertain if this is the only change necessary.

Bonus: Would be cool to have a matching heuristic for this that looks for existing configuration files / config in package.json and makes better recommendations based on the existing bundler.

I used markdown-it in my project, when I run npx @pika/web it threw an error

⠋ @pika/web installing... Error: You must supply options.input to rollup
    at /Users/Secbone/.npm/_npx/78950/lib/node_modules/@pika/web/node_modules/rollup/dist/rollup.js:16343:23
⠼ @pika/web installing... markdown-it

It will hang on forever.

It would be great to add caching so if the version of the package has not change it does not re-install it.

If I find some time I can work on this.

https://cdn.pika.dev/tippy.js/v4 (popper.js dependency bundled in)

vs

https://unpkg.com/popper.js@1

It's not being minified fully (function names, etc, are still the same as unminified). This leads to a +1 KB increase

Update from maintainers: See discussion below for updated issue: #12 (comment)

I use pnpm as an alternative npm client (because it uses a central module repo and symlinks, which saves tons of disk space). When following the guide in README, I replaced this line:

$ npx @pika/web

with

$ pnpx @pika/web

which gave error:

npx: command not found: web

So looking further down at the optional npm prepare script step, I saw that referenced "pika-web" and tried that instead:

pnpx pika-web

Which seems to have worked much better. Not sure if the original version works properly with npx as I don't use it, but this version definitely seems better on pnpx.

I have configuration like this:

{
  "@pika/web": {
    "webDependencies": [
      "js-beautify/js/src/javascript/index.js"
    ]
  }
}

I would like to have output path, for example:

{
  "@pika/web": {
    "webDependencies": [
      {
        "source": "js-beautify/js/src/javascript/index.js",
        "destination": "js-beautify/js-beautify.js"
      }
    ]
  }
}