Module not found: Error: Cannot resolve module '...' in /api/sandbox/...

[drcmda]

I am trying to get this running: https://github.com/awv3-next/example-simple

It has a single npm dependency (next to babel and webpack), "awv3". This one has sub-dependencies like three.js. Setting it up in webpackbin it first complains about

import THREE from 'three';

Saying it doesn't find 'three', does it load npm package dependencies into the sandbox by itself?

The next one is:

import Canvas from 'awv3/core/canvas';

Saying it cannot find module 'awv3/core/canvas', but i don't understand why. If you look into the demo example, it is straight forward, there's nothing to it: https://github.com/awv3-next/example-simple/blob/master/webpack.config.js

Thanks for all the hard work, this looks very promising!

[christianalfoni]

Hi there!

I am not sure what happens with three, have to test that. You used the configurator and added it there?

That canvas thingy has a nested entry point, which Webpackbin does not support "out of the box". It is a trade off. Webpackbin can load deps extremely fast, but it has to know all the entry points in advance. So by default Webpackbin loads entry points based on the "main" prop in package.json. But some packages has direct entry points which are impossible to figure out automatically as the folder structure can be very different on different projects. So now I manually add these extra entry points on projects that needs them.

If you could list the entry points of Canvas here I can add them on next release :)

[drcmda]

@christianalfoni

Hi! Thanks for the quick response!

I used the configurator and added the package. It has 'three' declared as a dependency in its package.json among some others. It would be nice if these would go straight into the sandbox. Npm does this automatically normally, while webpack resolves to node_modules by default.

As for nested entrypoints, these are just commonJS modules requiring other modules. I usually have one entrypoint leading to the main application (index.js), webpack then crawls through the dependencies and creates a bundle. The library has many modules, it would be tough to track them manually with entry-points.

Can webpackbin not just let webpack do its crawling? Normally you just npm install packages and use them straight away via require or import, without having to add additional entry points to the webpack.config.js file.

[christianalfoni]

Hi again :)

Let me explain a bit better, heh.

Normally when you add a package it resolves as normal. So you just add it via the configurator, save the project and then it is available to you.

What I really mean by entry points is not related to dependencies. Let us take lodash as an example. Normally you use:

import {map, each} from 'lodash';

So you point to lodash directly, where webpack uses the package.json file to find the main property that points to the library entry point. But Lodash also allows:

import flatMap from 'lodash/fp/flatMap';

Lodash package.json file says nothing about this fp directory. So it needs to be manually added inside webpackbin service. So with your example:

import awv3 from 'awv3';
import Canvas from 'awv3/core/canvas';

Webpackbin needs to know about /core as it is a sub-directory with detached entry points. Maybe awv3 only allows you to grab stuff from /core and then that is enough configuration for Webpackbin to understand it :)

The reason this can not be automated is that a lot of packages exposes a bunch of stuff on different directories. Like Angular2 exposes /dist which has a lot of different versions of the lib in built format, causing the NPM package loaded into the browser to be 70 MB, to allow you to load whatever from any subdirectory.

Hope that made sense, a bit difficult to explain :-)

[drcmda]

@christianalfoni Oh, that makes total sense. I will construct a flat index in the lib and tag it in package.json. I think it's even better that way, i like the lodash approach.

As for the npm package dependencies (three.js), are they available automatically or is this just an error build-up when i tried to import nested modules?

[christianalfoni]

Cool! :-)

The deps of a package are not accessible directly, you have to explicitly configure a package in the configurator to access it in your code. So if LibA depends on lodash you can not access import _ from 'lodash' in the code, have to add lodash explicitly to the configuration

[drcmda]

Thanks again! I got it working. :)

[christianalfoni]

Great stuff! :)

Let me implement a check if package configuration has changed when you close the configurator so that it saves automatically