[nstepien]

Imports in the module-level scope

Imports were kept apart from the scopes: their sources in importedIdentifiers, and the local names of ecij's css in cssTagNames. resolveValue only looked an import up once no scope bound the name, and the tag check combined both lookups. Imports are now bindings of the module-level scope, like its declarations:

• The scope chain finds them, so findBindingScope is the only lookup.
• resolveBinding resolves them next to const bindings, through a new resolveImport, which holds what was the import branch of resolveValue.
• The tag check reads the binding of the tag: ecij's css is { type: 'ImportBinding', source: 'ecij', imported: 'css' }, and a local binding of the same name shadows it, as before.
• ParsedFileInfo.importedIdentifiers and cssTagNames are gone.

Namespace imports are recorded as bindings with unknown values, which they were in effect before.

Default imports

A default import is now an import of the binding exported as default, like import { default as x }. export default binds its value to *default*, the local name the spec gives it, which no identifier can be. So the exported value resolves like a const initializer: a literal, a binding, or a css`` template, whose class name it takes, with its stylesheet imported first. Functions and classes exported by default don't resolve, like any expression resolveValue doesn't support, and a TypeScript interface binds nothing. The README no longer lists default imports and exports as missing.

Imports exported again

Values that a module exports as imported bindings now resolve in the module they are imported from. On #128, import { a } from './x'; export { a } didn't resolve, while export const b = a did. export { a } from './x' is still skipped, as it binds nothing in the module (the TODO: handle re-exports).

Cycles

Imports are cached with the const values of the transform (constValues is now bindingValues), unknown while they resolve. So imports that modules export to each other stay unknown instead of being followed forever. A new test covers it in the Vite dev server, which transforms modules one by one, as a bundle can't link such modules. Without the cache, the test worker runs out of memory within about 10 seconds.

Unsupported expressions

resolveValue now returns as soon as a literal or a unary expression turns out to be unsupported, so each expression type is handled in one place. A negated const (${-gap}), which stays unresolved, covers the unary case in the literal interpolation test.

Tests

The import-forms test, now named "resolve the supported import and export forms, and skip the others", covers:

• default imports, of a value and of a class name
• an interface exported by default
• a value and a class name exported again
• members of a namespace import, which stay unresolved

The uncovered lines are unchanged from #128, with one fewer uncovered branch.

The two guards of resolveImport are one-liners, like the one in resolveImportedModule, as an import that can't be resolved stays untested. AGENTS.md now says that imports are module-level bindings, where default exports are bound, and that cycles through imports stay unknown.

Benchmarks

The JS, CSS, and final source maps of the benchmark builds are unchanged, react-data-grid's included, and their timings moved by a few percent in both directions against #128.

🤖 Generated with Claude Code

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: nstepien/ecij
• Branch: root-scope-imports
• File: .coderabbit.yaml
• Commit: 2195bc4
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: dbb91a3b-b975-4b2b-81b0-738b73f86440

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn