Move to ESM modules #8460
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,7 @@ | ||
| export * from '../layers/bundle/peer-dependency'; | ||
|
|
||
| // Import from package name instead of relative path | ||
| // This will be resolved to src or dist by esbuild depending on bundle settings | ||
| // dist has TS transformers applied | ||
| /* eslint-disable import/no-extraneous-dependencies */ | ||
| export * from '@deck.gl/aggregation-layers'; | ||
felixpalmer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,7 +16,7 @@ import { | |
| vectorQuerySource, | ||
| vectorTableSource, | ||
| vectorTilesetSource | ||
| } from '../sources/index'; | ||
|
There was a problem hiding this comment. We could avoid all these There was a problem hiding this comment. Note that these import paths don't just affect source code, they also persist into
Ideally — I think we should either go one step further and add There was a problem hiding this comment. .js extension is added with a custom typescript transform, hence We could alternatively write all the extensions into src, I was trying to avoid too many changes. There was a problem hiding this comment. I'd missed the custom TS transform, that sounds like a good solution to me! One other option would be to bundle the type definitions into a single file with something like tsup or dts-buddy — no need for extensions if there are no imports! — but if the custom TS transform is working already, I'd vote for that. 👍🏻 There was a problem hiding this comment.
|
||
| import {parseMap} from './parse-map'; | ||
| import {requestWithParameters} from './request-with-parameters'; | ||
| import {assert} from '../utils'; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,7 @@ | ||
| // @ts-nocheck | ||
| import {getLoggers} from '@deck.gl/core/debug/loggers'; | ||
|
|
||
|
There was a problem hiding this comment. Q: Do we even need this module? It only seems to repackage core stuff? Something we could drop in v9?Are we trying to replace a call to There was a problem hiding this comment. This importing from module subpaths is a bit of a yellow flag to me. It has caused me a lot of problems in the past with various build tools, so I would avoid it if possible. Maybe just export There was a problem hiding this comment. The whole point of this file is to NOT include verbose debug messages in the main bundle. https://deck.gl/docs/developer-guide/debugging#deckgl-logging The import path is not exposed by the published package. This file is only used when building debug.min.js. |
||
| const loggers = getLoggers(globalThis.deck.log); | ||
| globalThis.deck._registerLoggers(loggers); | ||
|
|
||
| export {loggers}; | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,19 @@ | ||
| // @ts-nocheck | ||
| // Luma and deck core must be imported before `global` | ||
| /* eslint-disable import/no-extraneous-dependencies */ | ||
| import * as LumaGL from '@deck.gl/core/scripting/lumagl'; | ||
| import * as LoadersGL from '@deck.gl/core/scripting/loadersgl'; | ||
|
|
||
| globalThis.luma = globalThis.luma || {}; | ||
| globalThis.loaders = globalThis.loaders || {}; | ||
|
|
||
| Object.assign(globalThis.luma, LumaGL); | ||
| Object.assign(globalThis.loaders, LoadersGL); | ||
|
|
||
| // Import from package name instead of relative path | ||
| // This will be resolved to src or dist by esbuild depending on bundle settings | ||
| // dist has TS transformers applied | ||
| export * from '@deck.gl/core'; | ||
| export {register as _registerLoggers} from '@deck.gl/core/debug'; | ||
|
|
||
| export {default as DeckGL} from '@deck.gl/core/scripting/deckgl'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: If the
*notation works, might be useful for both luma and loaders? Any reason not to?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The luma and loaders global objects are to make sure that there is only one copy of a module. User access of the exported classes is just a bonus. This is also the reason why I'm not cherry picking the exports - what's exported is not determined by their usefulness, but by necessity if they are referenced anywhere in the code path. If we cherry pick, it's going to be a long list due to the sprawling interface between deck and luma, and the list has to be re-audited every time we make a change.