Runtime client error, "Failed to resolve module specifier '', when adding component, Reverting does not fix

[goblinfactory]

Runtime error after adding "component"

WHEN

• adding a custom nue component to the starter simple-blog website
  THEN
• get the following runtime client error in browser (tested with Chrome and Safari)

Uncaught (in promise) TypeError: Failed to resolve module specifier ''
    at importAll (mount.js:18:21)
    at mountAll (mount.js:26:30)
    at mount.js:49:33
    at mount.js:50:44

WHEN reverting
THEN bug does not go away.

Environment

- OS: OSX
- bun
- bun
- Nuekit Version: ✓ Nue 1.0.0-beta.1 • Bun 1.1.27 

Minimal Reproduction

1. create empty folder test-nue, cd test-nue
2. run nue create // nue creates simple-blog starter
3. cd simple-blog
4. run nue, open browser, and press F12, observe no errors in Console.
5. Add folder /components, add file, pill.nue or pill.html (either, doesnt matter)

<div @name=pillar class="pill">
    <h1>hello</h1>
</div>

6. update /index.md add the [pillar] component markdown to index.md immediately above [gallery]

[pillar]
[gallery]

7. refresh browser; Press F12, view console output, observe error

mount.js:18 Uncaught (in promise) TypeError: Failed to resolve module specifier ''
    at importAll (mount.js:18:21)
    at mountAll (mount.js:26:30)
    at mount.js:49:33
    at mount.js:50:44

8. revert everything,
9. delete component folder,
10. remove [pillar] from index.md
11. stop nue. (control+c)
12. delete .dist folder
13. restart nue
14. simulate clearing browser cache by opening chrome guest view
15. observe the error remains??? <-- this one is really strange.
16. If you delete the whole folder and start over, it all works, and everything behaves again exactly as described, error comes back, it persists etc.

[nobkd]

This error happens, while the components are mounted, when the component js is not included / the component does not exist.

I actually can't reproduce this issue at all.

---

Edit:

Oh... you save your component to components subdir. (I always just added the component to the project root while testing...)

You'll have to add components-dir to the globals array in your site.yaml:

# site.yaml
globals: ["@global", components] # or just move the component to @global and use the default simple-blog config

OR to your libs array, and include: [pill] (uses component's filename) in your md page (which doesn't make sense for layout components):

# site.yaml
libs: [components]

---
# index.md
include: [pill]
---

[pillar]

Let me know if this solved your issue.

[goblinfactory]

@nobkd
It's a new day, and new behaviours; I'm now unable to reproduce the situation where the bug persists after reverting; It's a new day and I started by rebooting my system.
I will see if I can find out the exact steps and conditions that caused this since I did about 5 tests yesterday, each time starting from totally clean directory and the persistent errors was a real issue I observed yesterday.
I am wondering if perhaps I had opened a number of projects and changed the port on one, since all the project instances were exactly the same, it's easy for me to accidentally test on the default port, which of course would not "go away" after reverting. (that would explain it)

Txs for looking into this, much appreciated. I think we'll probably close this issue shortly if I cannot find the exact steps to reproduce, write this off as due to multiple test instances running, and instead focus on a new issue i will raise with respect to better error message if component is not found.

Also, update to the documentation where we need better worked examples of how to create a markdown extension (component) which needs to include steps that can be verified, so that we can "prove" that the documentation is valid.
(in previous .NET projects I have worked with clients to actually have the documentation pull in the "examples" from real tests, using Simon Cropp's Markdown snippets so your documentation MUST always include real compiled, tested examples that are guaranteed to run with the latest version of the software. Documentation Pull requests are reviewed to ensure that any additional documentation is ALWAYS accompanied with a worked example. So that it's reasonable to say, if you're writing documentation to tell someone how to attach a FooA to a FooB, that you can prove that the way you're telling people how to do it, ACTUALLY works, and is up to date and current with the latest code.

With markdownsnippets; you define a snippet, anywhere in code; most often integration test code, that works as follows

// begin-snippet: MyFooSnippet
My Snippet Code
// end-snippet

then you simply import the snippet in your documentation markdown, using a token, and a pre-processor in your build step that simply does a text replace.

# some heading about Foo
Some blurb about Foo
snippet: MyFooSnippet

which after your build runs turns into

# some heading about Foo
Some blurb about Foo

    // how to add Foo to Bat
    const foo = createFoo( { .. });
    ...

Which is GUARANTEED to be the right example that works with the version of the code that your reader would download.

[goblinfactory]

@nobkd I'm going to close this as not a bug,(github "not planned") and raise a new issue for smarter error messages when user mistypes a markdown extension.

update : done #350