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

pass correct scope to glimmer #33

Merged
merged 17 commits into from
Apr 17, 2024
Merged

pass correct scope to glimmer #33

merged 17 commits into from
Apr 17, 2024

Conversation

patricklx
Copy link
Contributor

@patricklx patricklx commented Mar 9, 2024

It was in a sense useful that it would prematurely catch missing imports or definitions for template locals.
But with today's state of glint and eslint we do not really need this anymore.
It also prevents use of web components and specifying components for known html elements did also not work.
also fixes usage of svg elments

fixes glimmerjs/glimmer-vm#1550

look at
df34cb4 for tests diff

@patricklx patricklx marked this pull request as draft March 11, 2024 08:51
@patricklx patricklx changed the title pass local scope to glimmer pass correct scope to glimmer Mar 12, 2024
@patricklx patricklx marked this pull request as ready for review March 12, 2024 07:02
@patricklx patricklx closed this Mar 18, 2024
@patricklx patricklx reopened this Mar 18, 2024
@patricklx patricklx closed this Mar 18, 2024
@patricklx patricklx reopened this Mar 18, 2024
src/plugin.ts Outdated
@@ -483,7 +509,8 @@ function insertCompiledTemplate<EnvSpecificOptions>(
backingClass: NodePath<Parameters<typeof t.callExpression>[1][number]> | undefined
) {
let t = babel.types;
let scopeLocals = buildScopeLocals(userTypedOptions, config, template);
target.state = state;
Copy link
Sponsor Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why's this needed? why not pass state to buildScopeLocals?

Copy link
Sponsor Contributor

@NullVoxPopuli NullVoxPopuli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a test? thanks!
oh, and an additional test that shows that yield defined in JS scope overrides the keyword yield?

@patricklx patricklx marked this pull request as draft March 20, 2024 13:27
@patricklx
Copy link
Contributor Author

patricklx commented Mar 20, 2024

Not ready after all, block params scope should not apply to own attributes or modifiers. Currently that happens. Not sure why the tests are passing.
I'm refactoring this

src/plugin.ts Outdated
enter(_node, path) {
const blockParams = (path.parentNode as any)?.blockParams;
if (blockParams && ['children', 'body'].includes(path.parentKey!)) {
astScope.push(blockParams);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we just push the block params array, since its the same instance we can easily remove it at exit

src/plugin.ts Outdated
@@ -437,6 +490,9 @@ function buildPrecompileOptions<EnvSpecificOptions>(
},
};

const locals: string[] = [];
output.plugins?.ast?.push(discoverLocals(target, state, locals, scope));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we push our own locals discovery ast plugin, which mutates the locals passed to precompile.
@chancancode if you have a better option, now is the chance :)

src/plugin.ts Outdated
@@ -513,6 +569,8 @@ function insertCompiledTemplate<EnvSpecificOptions>(
configFile: false,
}) as t.File;

scopeLocals.locals.length = 0;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reset scope locals and set it to the ones discovered at the end. As ast plugins could have removed previously added locals.

@@ -574,14 +632,14 @@ function insertTransformedTemplate<EnvSpecificOptions>(
let transformed = print(ast, { entityEncoding: 'raw' });
if (target.isCallExpression()) {
(target.get('arguments.0') as NodePath<t.Node>).replaceWith(t.stringLiteral(transformed));
if (!scopeLocals.isEmpty()) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scope locals could have changed from something, to empty, we need to remove existing scope

@@ -31,7 +31,15 @@ export class ScopeLocals {
}

entries() {
return Object.entries(this.#mapping);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only use mappings for actual scope

@patricklx patricklx force-pushed the patch-3 branch 5 times, most recently from 47c1e57 to 069fa3e Compare March 21, 2024 12:44
Made while pairing with @patricklx.

 - keep a single locals list instead of synchronizing two different ones
 - update jsutils to always rely directly on Babel's bindings, not ScopeLocals
- reuse the hbs-scope-traversal scope from jsutils instead of introducing a second implementation
@ef4
Copy link
Contributor

ef4 commented Apr 12, 2024

@patricklx and I paired on this and it's getting close to done. The remaining task is to add a test for removing things from locals, because we think we might not have that case done yet.

@ef4 ef4 dismissed NullVoxPopuli’s stale review April 12, 2024 22:44

Test was added as requested

ef4 added 2 commits April 12, 2024 20:46
The explicit scope form doesn't automatically bind to javascript. It's different from the implicit-scope-form, which does.

The only modifications we should be making to the scope bag in explicit form are modifications caused by AST transforms. (Dropping unused is also a safe transformation and can stay.)
@ef4
Copy link
Contributor

ef4 commented Apr 13, 2024

While testing this I realized we're now doing too much. In the explicit scope form, we're not supposed to magically bind to javascript values in scope. That's only supposed to happen to the implicit form (the one that has eval to indicate that it has access to all surrounding javascript scope).

The only modifications we should be making to the scope bag in explicit form are modifications explicitly asked for by AST transforms. (Dropping unused names is also a safe transformation and can stay.)

@patricklx
Copy link
Contributor Author

@ef4 reverted some parts and updated tests

@ef4 ef4 merged commit bbf5ac2 into emberjs:main Apr 17, 2024
4 checks passed
@ef4 ef4 added the bug Something isn't working label Apr 17, 2024
@ef4
Copy link
Contributor

ef4 commented Apr 17, 2024

Thanks for all the work on this. Released in 2.2.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants