-
Notifications
You must be signed in to change notification settings - Fork 51
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
use new glimmer ElementNode sub nodes #696
base: main
Are you sure you want to change the base?
Conversation
4e5ee8b
to
d7f88cb
Compare
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.
there are a lot of noisy changes here -- can you reduce the diff to what was meaningful? thanks!
4a810e2
to
23ef8a2
Compare
23ef8a2
to
f0bf4c4
Compare
@NullVoxPopuli any idea how I can fix this:
|
Does skipLibCheck help? Otherwise, glimmer has more bugs we need to fix (all relative imports should always use extensions when using node16, so it shouldn't be too bad of a fix) |
yes, it helped! |
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.
what's up with these changes? 😅
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.
i'm not sure... i just run vite --update & prettier
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.
ah, wait, I did add a space in case its empty attributes
tsconfig.compileroptions.json
Outdated
@@ -11,6 +11,7 @@ | |||
"composite": true, | |||
"declaration": true, | |||
"sourceMap": true, | |||
"skipLibCheck": true, |
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.
this may be controversial with the former ember-TS members, but I don't know of another way to have a node16 project interoperable with non-none16 projects
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.
I would prefer to fix this issue upstream in the glimmer side. skipLibCheck
is a pretty blunt tool that can hide problems globally (since type failures in a library can generate any
s that then propagate through our own code).
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.
@patricklx would there be any noticeable editor behavior changes with this PR? (or is it "just the same, but using the new parser capabilities"?) |
i'm not seeing and difference |
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.
Let's block on glimmerjs/glimmer-vm#1555
And get that update in here, too once released
@patricklx new versions published, can you try the .1 release? |
nope, some new errors-...
microsoft/TypeScript#52529 looks like @ef4 knows something about this |
ah yeah, we're probably blocked on ember-source needing to actually ship as a |
@NullVoxPopuli the error is under @types folder. And here? |
does changing all of |
it fixes some errors, still, at the end it says |
Ahh, yeah, probably because all the private relative imports need extensions at that point. Hmm |
I've added skipLibCheck back. It doesn't seem we can build without it. |
… all the @types to ESM, which would break ember apps, etc
@patricklx FYI 0.89.0 is out with glimmerjs/glimmer-vm#1568 The information you need should now be in Should also fix #706 |
sourceNode.type === 'ElementNode' | ||
? sourceNode.tag.split('.')[0] | ||
sourceNode.type === 'ElementNameNode' | ||
? sourceNode.value.split('.')[0] | ||
: sourceNode.type === 'PathExpression' && sourceNode.head.type === 'VarHead' |
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.
This kind of stuff should now work better, since ElementNode
, MustachesStatement
and SubExpression
all have the same path
property
@@ -1,4 +1,5 @@ | |||
import { SafeString } from '@glimmer/runtime'; | |||
// @ts-expect-error cannot import, but we only need the type... | |||
import type { SafeString } from '@glimmer/runtime'; |
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.
Why did it stop working? It seems to be here: https://github.com/glimmerjs/glimmer-vm/blob/v0.89.0/packages/%40glimmer/runtime/index.ts#L43
And I don't think we would want @ts-expect-error
here, if the only reason we want to import it is for the type, but specifically the type import wasn't working, what does this even do? (making it any
, probably)
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.
This was the error:
https://github.com/typed-ember/glint/actions/runs/7712187814/job/21019163076#step:9:139
tests__/emit-content.test.ts(1,28): error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@glimmer/runtime")' call instead.
there are now also following nodes:
example:
afterwards completions/validations can be add for attributes and element tags
In #663