Configure ocular to build only the esm bundle about manifold HOT 11 CLOSED

I suspect that adding a configuration to only build some "dists" would be a fairly simple modification to ocular, I could walk you through the ocular code and show you where to make changes.

Before you go there, I have one big concern you may want to verify:

Apart from the support for multiple dists, something that we feel is critical is the ability to build examples directly against local src rather than against published packages, which we do with webpack aliasing (our examples/webpack-config-local setups).

I remember that having sub-package imports caused major problems, and this may have been the other major reason we abandoned this.

Perhaps it is possible if you define a big set of aliases covering all your import paths? Perhaps this alias generation can be automated by ocular by looking for all .js files in the root folder.

Either way, I'd strongly recommend verifying that you have src build working in your examples before you go to far down the subdirectory import road.

from manifold.

Either way, I'd strongly recommend verifying that you have src build working in your examples before you go to far down the subdirectory import road.

@Firenze11 were there some subdirectory import in the example/ and website/ folder before you refactored the code. If so, then it seems src build with subdirectory was working with our aliasing approach.

from manifold.

I checked it. There is a line import {loadLocalData} from '@mlvis/manifold/actions' which is clearly a subfolder import. Our aliasing approach was able to handle this type of imports.
@ibgreen In case you haven't seen it, the aliasing looks like this:

const resolve = require('path').resolve;
const fs = require('fs');

const ROOT = resolve(__dirname, '.');
const MODULES_ROOT = resolve(ROOT, 'modules');

const AliasConfig = modulesDir => {
  const mdir = modulesDir || MODULES_ROOT;
  // this function looks into all packages under ./src and creates alias for local dev
  // {@mlvis/some-package: './modules/some-package/src'}
  return () =>
    fs.readdirSync(mdir).reduce((aliasMap, pkg) => {
      // src/some-package
      const packagePath = resolve(mdir, pkg);
      if (!fs.lstatSync(packagePath).isDirectory()) {
        return aliasMap;
      }
      // packages/some-package/package.json
      const packageJsonPath = resolve(packagePath, 'package.json');
      // bypass alias mapping if no package.json exists
      if (!fs.existsSync(packageJsonPath)) {
        return aliasMap;
      }
      const packageInfo = require(packageJsonPath);
      // @mlvis/some-package => some-package
      const packageName = packageInfo.name.replace(/^(@mlvis\/)/, '');
      aliasMap[packageInfo.name] = resolve(mdir, packageName, 'src');
      return aliasMap;
    }, {});
};
module.exports = AliasConfig(MODULES_ROOT);
module.exports.AliasConfig = AliasConfig;

And we use it as such:

const AliasConfig = require(resolve(ROOT, 'alias.config.js')).AliasConfig;
const getLocalModuleAliases = AliasConfig();
const getJupyterModuleAliases = AliasConfig(JUPYTER_MODULES);

...

    resolve: {
      extensions: ['.js'],
      alias: {
        ...
        ...getJupyterModuleAliases(),
        ...getLocalModuleAliases(),
      },
    },

from manifold.

Got it. My thoughts:

1. That is a lot of complex alias handling to have in an app. ocular has built-in alias handling that looks very similar, that is provided through an exported symbol. This should probably be handled by ocular.

2. I am not yet convinced that this works as intended. In my experience, webpack alias have some special semantics around subdirectory files

So, if you run your example in local mode and put a breakpoint in one of the files imported with subdirectory import, are you getting the one from the src or the dist?

It could be that it runs, but you are actually importing a mix of files from src and dist which could lead to very painful and subtle issues down the road.

If you can verify that it works, that is great. Just trying to make sure you avoid a painful discovery after you go too far down this path.

from manifold.

I am not yet convinced that this works as intended. In my experience, webpack alias have some special semantics around subdirectory files

I get what you mean and I now have the same concern.

So, if you run your example in local mode and put a breakpoint in one of the files imported with subdirectory import, are you getting the one from the src or the dist?

I did two things to try to verify this:

1. put a breakpoint in modules/manifold/src/action:

2. completely delete the dist/ in modules/manifold.

Then

cd website/
yarn start

It does seem that the aliasing is working as intended, which is quite surprising.

from manifold.

https://webpack.js.org/concepts/module-resolution/#module-paths

> If there is no package.json or if the main fields do not return a valid path, file names specified in the resolve.mainFiles configuration option are looked for in order, to see if a matching filename exists in the imported/required directory .

Does this suggest why it works.

P.S. I misread this and this is not related to our problem.

from manifold.

I didn't get it why it is surprising that that aliases worked. The aliases was set up precisely for importing from src folder, in order to support local development. I don't think recent changes (adding ocular) has changed that.

from manifold.

@Firenze11, Based on my understanding, @ibgreen was referring to the alias cases specified here: https://webpack.js.org/configuration/resolve/#resolvealias. Our use case is specified here:

I guess this is the reason why it works.

from manifold.

@kenns29 Right, our alias.config file has always been using webpack resolve.alias, and we are still using it after we added ocular to the repo

from manifold.

OK great. As far as I can see your alias setup is similar to ocular's. As I recall, I did not get this working in my testing but that was some time ago and issues might have been unrelated.

FWIW, I would certainly appreciate if manifold used ocular's alias system:

• https://github.com/uber-web/loaders.gl/blob/master/examples/webpack.config.local.js#L12
• https://github.com/uber-web/ocular/blob/master/modules/dev-tools/config/ocular.config.js)

and confirmed that it worked with the subdirectory setup (if not we should see if we can fix it), that would be very valuable to other modules that want to use this import system.

from manifold.

Resolved

from manifold.