fix "is not a module" #2603 #2606
Conversation
|
You can introduce support for Basically, you could do it for However, I think it is not possible to do something for Also, the types are not exported and available in TS (only the hljs object). It would require something different to also export the types. IMHO, the easiest solution would be to migrate to TS and generate the declaration files via tsc. However, this would require some extra work to get the CJS version right. |
|
I don’t want type files everywhere. Does the ambient module stuff simply not work at all? Why is it in the documentation? It looks like the perfect solution to this and I see lots of packages on @types that seem to be using it. Example: |
|
You could try something like this (omitting the extension): declare module 'lib/language/basic' {
export = fn;
}(When importing, the .ja extension is optional in TS). fn being a const of the languageFn. Not tested. |
|
I've been trying that, but nothing works so far. I guess today I'll try to find an NPM package and @types that actually seems to work correctly and then try to extrapolate from there. |
|
I created a typing file for each submodule, and changed the types in the package.json to get the typing files out of the "types" folder. I realized that there are two HLJSApi interfaces, I commented one because I didn't really understand the reason for having two. I need help with that. It was also not very clear to me, what are the differences in the "highlight.js", "index.js" and "core.js" interface, I left them all the same. It would be good for someone to review this. |
|
Can you please provide thoughts on #2608 This seems to work in my testing. And it supports not just pulling in the library itself, but also the variations people do most often. |
|
Oh I'm just now seeing this, let me have a look. |
|
I think ambient modules are much cleaner, no? |
It's just extending the first, this is a feature of TS. I was trying to separate the mode helpers from the main API... though perhaps I should instead do this with a second interface and then extend it... or a
Well |
I did several tests, this was the only way I managed to make it work lol I tried the way here #2608 but was unsuccessful. |
Can you show me how you were unsuccessful or show me your test cases? |
|
@rodrigojcmello How to structure the type file is a whole other discussion. :-) I'm sure it could be improved greatly and perhaps it should be more "type definition like". I'm not sure yet. Right now I'm just first trying to solve the basic issue of importing our library in a TS project without blowing up. :) |
Here it is not clear whether you tested #2606 or #2608 I didn't get to test the #2608, yesterday I did something like that and it didn't work out. I'm going to test #2606 now. |
|
I didn’t test 2606. I’ve very not interested in multiple files - if we can handle this instead with a single file and ambient modules. Which seems like they were designed for exactly this purpose |
| install("./types/types.ts","lib/types.ts"); | ||
| install("./types/core.d.ts","lib/core.d.ts"); | ||
| install("./types/highlight.d.ts","lib/highlight.d.ts"); | ||
| install("./types/languages/basic.d.ts","lib/languages/basic.d.ts"); |
There was a problem hiding this comment.
There are 180+ languages... this is why I'm not a fan of the individual file approach here.
|
Apparently the #2608 works very well. My test yesterday probably failed because I declared the modules at the beginning of the file. Anyway, this solution is even better. 🥇 |
No description provided.