Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems using the module build #427

Open
martinxyz opened this issue Nov 17, 2022 · 3 comments
Open

Problems using the module build #427

martinxyz opened this issue Nov 17, 2022 · 3 comments

Comments

@martinxyz
Copy link

We're trying to embed Neuroglancer (master) into an Angular project.

Attempt: Consume the module build

Building the module with npm run build-module worked fine. But following the readme from examples/dependent-project I was unable to get the example to work. I think it's because the example uses webpack, while the main project has switched to esbuild.

So the dependent-project seems unmaintained? (If so, maybe add a note about that?)

Importing and calling setupDefaultViewer() from Angular (via npm link) didn't work:

  • Got many different typescript and build errors. After fixing includes and tsconfig, the main issue was css/svg import statements in the built module dependencies. Angular's Webpack didn't want to resolve those (build errors). Plus some issues with the codemirror dependency that emitted compatibility-import statements that work in the browser, but caused errors from when bundling with Angular. After fixing those directly in node_modules, @babel/runtime was missing, etc.
  • Also types didn't work, but that's easy to ignore for now. I understand we cannot generate type definitions because of this typescript issue with mixins.
  • Conclusion: We probably should consume a build already bundled by esbuild.
    • Which implies that the Angular project shouldn't depend on neuroglancer's dependencies (package.json) any more.
  • Attempted to change config/esbuild/ to create a module build with bundle: true,. Got it to build, but didn't find the module entry point in the bundled result.

Do you think it is useful to proceed with that approach? (Would you want a PR doing a bundled module build?)

Alternative: Embed the main build via <iframe>

This is described in this comment from issue 324 and works just fine so far. We can access the viewer object from the <iframe>'s window, configure it, even subscribe to events.

The main drawback seems to be that we cannot import and control the initial config / viewer creation.

@jbms
Copy link
Collaborator

jbms commented Nov 29, 2022

You are correct that the dependent-project example is out of date. Note though that the module build is unrelated to that example --- it was added to support https://github.com/neuroglancerhub/react-neuroglancer

In general there are 3 ways to consume neuroglancer as a dependency:

  1. Bundle it directly as part of your project's build. Cleanest and most flexible but requires most complex build configuration. This is a what the dependent-project did, but as noted it is now out of date.
  2. Bundle the workers ahead of time, consume main thread sources directly as esmodules. This is what the module build supports, but it is somewhat specialized for Janelia's use case currently.
  3. Use an iframe. Simplest but least flexible.

@martinxyz
Copy link
Author

Thanks for clarifying. We're still playing around with those options.

With the iframe approach we also got types on the viewer object to work, via /// <reference path="../lib/neuroglancer/typings/index.d.ts" />. This required a lot of fiddling with tsconfig.json, probably because we're using typescript 4.7.2, while neuroglancer is at 4.3.2. So here are the relevant options that work for referencing an unmodified neuroglancer (v2.31):

  "compilerOptions": {
    "strict": false,
    "noImplicitOverride": false,
    "noPropertyAccessFromIndexSignature": false,
    "strictPropertyInitialization": false,
    "useUnknownInCatchVariables": false,
    "strictNullChecks": true,
    "noImplicitAny": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": false,
    "downlevelIteration": true,
    "experimentalDecorators": true,
    "noImplicitThis": true,
    "noUnusedParameters": true,
    "noUnusedLocals": true,
    "preserveConstEnums": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "es2020",
    "module": "es2020",
    "lib": [
      "es2020",
      "dom",
      "dom.iterable"
    ],
    "typeRoots": [],
    "paths": {
      "neuroglancer/*": [
        "lib/neuroglancer/src/neuroglancer/*"
      ]
    }

@Tomaz-Vieira
Copy link
Contributor

What would we need to get an actual node package for Neuroglancer working, so that it could be imported like any other dependency? Is the problem just the css files and the different entry points for the web workers?

Right now I'm essentially forking Neuroglancer in order to use it as a "dependency".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants