Comments (15)
When you use --dependencies
it will try to find manifests of other libraries in your node_modules
, and if any components from those libraries are used/extended, it will supplement the data for your current projects manifest.
To clarify, here's a run without --dependencies
:
You can see the manifest includes the superclass
as being from a third party package, but none of the methods inherited by GenericTabs
are output in the manifest.
When I use --dependencies
, the inherited methods of GenericTabs
(and whatever else that inherits, in this case its GenericTabs -> SelectedMixin -> BatchingElement
), are also included in the classDoc
of MyEl
:
from custom-elements-manifest.
Ok I think this thread is probably user error on my part so apologies from the confusion. I need to investigate those two seperate points myself.
Alright, I'll close this issue then if that's okay with you :)
Yes, but I only recently became aware of that after I had already started my investigation
It happens :) Different approaches are healthy 👍 Maybe there's an opportunity for collaboration, or to learn from eachother. Would love to see the result of your project when its finished!
from custom-elements-manifest.
Yes I am happy for you to close this issue, thanks for spending the time investigating and explaining.
Also yes, I am going to carry on my proof of concept investigation for now and will hopefully be able to share my findings once I have. Then I can take the decision from there about whether it is worth continuing/using Matsuu's instead/or even collaborating on one together
from custom-elements-manifest.
@matteematt the CELS has a detached core that uses typesript and CEM and doesn't fixate on implementation details.
As for tsconfig setup vs LSP, I prefer the LSP approach but understand that it might not fit your cases but would be open to discuss in github issues or discord
from custom-elements-manifest.
With regards to the first issue, there is something wrong with the path globbing. If I do some debugging to print
then it isn't picking up manifest from the node modules:fullPathGlobs [
'/project/client/web/src/custom-elements.json',
'/project/client/web/src/index.federated.ts',
'/project/client/web/src/index.ts',
'/project/client/web/src/types.ts',
'/project/client/web/src/components/components.ts',
'/project/client/web/src/components/index.ts',
'/project/client/web/src/routes/config.ts',
]
If I change the glob to node_modules/@pkg/**/*.{js,ts,json}
then I just get
fullPathGlobs []
Also if I hardcode the path as the glob node_modules/@pkg/pkg/dist/custom-elements.json
then I still get no match.
from custom-elements-manifest.
Ok so I have found the reason for the first issue
The fact that ignore is ignoring the node modules and is the last thing which is mixed into the merged glob array is blocking my glob. Perhaps we need to disable that glob being added if we have the --dependencies
flag? Or if we mixin ...IGNORE
first then we can let users override the node modules ignore with their own glob.
I am still observing the same issue from when I was copying the file out manually anyway though - I am only getting this extra empty section in my output manifest
"kind": "javascript-module",
"path": "node_modules/@pkg/pkg/dist/custom-elements.json",
"declarations": [],
"exports": []
},
from custom-elements-manifest.
With my second issue, I think I have tracked it down to an error being thrown on this line
It seems we are using es-module-lexer
on the json manifest which is a parse error (it seems to expect source files so I don't understand why we are feeding the json file in) which is throwing an error
from custom-elements-manifest.
So after seeing that it is expecting source files rather than the json manifest I changed my glob to look at source files in the appropriate node modules directory. It does parse them but it falls over constantly on errors like this
[CORE - CLASSES]: Looks like you've hit an error in the core library.
I think that this point with my investigation into the glob pattern done but a bit stuck on this current issue, it makes sense for me to wait for a maintainer to get back to me with thoughts on my findings, and whether there is some user error on my end
from custom-elements-manifest.
Thanks for your investigation! I'm unable to reproduce this locally. Would it be possible for you to make a minimal reproduction repo I could take a look at?
from custom-elements-manifest.
Thanks for the reply. Before I try to do that, can I clarify what --dependencies
is actually doing? Just to stress, analysing my local repo with its unadultarated typescript source files works perfectly. The issue that I am trying to also get the info of the web components from a library in the package.json into the same manifest
- Are we able to just supply the generated manifest from the library by itself? That is esentially what I was trying, but it was falling over when trying to parse the imports and exports from the json file
- Are we supposed to be feeding it the dist files from the library? I did end up trying that too, but it fell over on loads of different files
- Are we supposed to be feeing it the source files from the library? I presume this isn't it, as it would not be possible for us to get the typescript source file from the library
from custom-elements-manifest.
Ok to be honest then I don't think that is actually exactly what I want to do. I want to have both manifest files combined so I can just use the data for all of it. For reference I am trying to build an LSP plugin for custom elements which is using data from the manifest to completion and diagnostics. In this case would it be syntaxtically correct for me to just merge the modules arrays from the two files?
Regardless, I still think I do want the dependencies linked because if in the base repo we extend something from the library, we want relevent info about attributes on the elements we extend too. But I think for that if I am understanding you correctly, I don't pass it the glob for the node modules at all - the script should be working out what files we want from the node modules via the imports and exports of the local source files?
from custom-elements-manifest.
In this case would it be syntaxtically correct for me to just merge the modules arrays from the two files?
I think so, but you may have to adjust/correct paths
But I think for that if I am understanding you correctly, I don't pass it the glob for the node modules at all - the script should be working out what files we want from the node modules via the imports and exports of the local source files?
Yeah, this should be based on the source code and what the source code uses
For reference I am trying to build an LSP plugin for custom elements which is using data from the manifest to completion and diagnostics
Cool, have you seen https://github.com/Matsuuu/custom-elements-language-server ?
cc @Matsuuu
from custom-elements-manifest.
Ok I think this thread is probably user error on my part so apologies from the confusion. I need to investigate those two seperate points myself.
Cool, have you seen https://github.com/Matsuuu/custom-elements-language-server ?
Yes, but I only recently became aware of that after I had already started my investigation - I need to look at that properly. We have taken different approaches though. Mine is a typescript plugin so you'd install it via node and then into the tsconfig.json rather than it being an IDE plugin. For our specific use case that is better I think, but it still needs some thought
from custom-elements-manifest.
@Matsuuu sounds good. Github issues might be better for being public. Would I raise an issue on your repo?
from custom-elements-manifest.
@matteematt Sure! Go ahead
from custom-elements-manifest.
Related Issues (20)
- [Analyser][Schema] Using Typescript as input results in TS file path in `def.declaration.module` rather than complied JS output HOT 2
- [Analyzer] `InitializeParams` type missing from `index.d.ts` HOT 4
- Wrong parse Object from AST HOT 1
- "push is not a function of null" HOT 6
- Regression in `resolveInitializer` behavior in analyzer v0.9.1+ HOT 7
- [Analyzer] Broken manifest with new decorator standard "accessor" keyword HOT 4
- Objects that get spread into `properties` don't get read by the analyzer
- Support for ElementInternals state HOT 6
- [@custom-elements-manifest/analyzer] Move `@github/catalyst` from dependencies to peerDependencies
- The outdir in the config half-works HOT 4
- @attribute is not added to "attributes"
- properties initialized in the constructor don't get their JSDOC tags read HOT 1
- Access modifier issue on derived class
- Arrow functions not getting categorized properly HOT 1
- The analyzer doesn't ignore nested node_modules by default HOT 1
- add helper functions defineConfig and definePlugin
- Provide real name instead of alias
- code blocks with annotated event break JSDoc parsing
- feat: Allow excluding default plugins
- feat: Do not exclude @internal properties
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from custom-elements-manifest.