Docz: TypeError: n is not a function

[clock157]

Bug Report

docz: 0.12.17 & 0.13.5

To Reproduce
npx docz dev

/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@docz-core/dist/index.js:5227
        n({
        ^

TypeError: n is not a function
    at parseHtml (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@docz-core/dist/index.js:5227:9)
    at template (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@docz-core/dist/index.js:5365:21)
    at MiniHtmlWebpackPlugin.plugin (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@mini-html-webpack-plugin/index.js:17:33)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/HookCodeFactory.js:32:10), <anonymous>:12:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/Hook.js:154:20)
    at Compiler.emitAssets (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@webpack/lib/Compiler.js:363:19)
    at onCompiled (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@webpack/lib/Watching.js:50:19)
    at hooks.afterCompile.callAsync.err (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@webpack/lib/Compiler.js:552:14)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/HookCodeFactory.js:32:10), <anonymous>:15:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/Hook.js:154:20)
    at compilation.seal.err (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@webpack/lib/Compiler.js:549:30)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/HookCodeFactory.js:32:10), <anonymous>:9:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/Hook.js:154:20)
    at hooks.optimizeAssets.callAsync.err (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@webpack/lib/Compilation.js:1323:35)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/HookCodeFactory.js:32:10), <anonymous>:9:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/puwei/Dev/test/test_lib/test-library/node_modules/[email protected]@tapable/lib/Hook.js:154:20)

I flowed the minified code, found that e is string 'null', not null.

getHtmlFilepath = e =>
    e ? path.resolve(root$1, e) : fromTemplates("index.tpl.html"),
htmlTemplate = async e =>
    compiled(getHtmlFilepath(e), { minimize: !1, escape: !1 }),

so it complied an error:

 { Error: ENOENT: no such file or directory, open '/Users/puwei/Dev/test/test_lib/test-library/null'
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/Users/puwei/Dev/test/test_lib/test-library/null' }

[clock157]

bad:

good: an old repo(yesterday)

[Godsenal]

I have a same issue. As @clock157 said, html path is set to string 'null' when indexHtml option is set to default.

[aleen42]

Same issue, and how to fix it?

[Godsenal]

@aleen42 right now, set default value manually in doczrc.js works for me.

[aleen42]

Meet another problem when setting with null manually, and what value should I set?

Module not found: Can't resolve 'null' in 'xxx/.docz/app'

[clock157]

try to set empty string '' ? @aleen42

[Godsenal]

undefined works for me.

[aleen42]

It seems not, just wait for the offical workarounds.

[Emiliano-Bucci]

setting indexHtml to undefined works, but it leads (at least to me) to another error: Module not found: Can't resolve 'docz-theme-default' in...

[jedrichards]

I've just tried downgrading Docz to older versions, and getting the error all the way back to 0.12.5 when I gave up. Is the error to do with some child dep of Docz perhaps?

[aleen42]

@jedrichards Apparently due to sub-depedencies as there were no any recent commits today, when the problem arose.

[jedrichards]

@aleen42 I think so too. Incidentally my Gatsby build has also broken if I rm -rf node_modules && rm yarn.lock && yarn install, so I think there's a bad sub-dep somewhere.

[chpwssn]

@jedrichards if you had the yarn.lock in version control before your rm -rf node_modules && rm yarn.lock && yarn install would diffing the previous version against your current yarn.lock reveal some potential candidates for what has changed?

[JustFly1984]

I'm confirming an issue, but I've updated from 0.12.15 to 0.13.5 with npm accidentally. and now reverting it back doesn't help. cleaning node_modules, package-lock.json and yarn-lock.json does not help.

[kettanaito]

Experiencing the same issue. Fresh installation, never used docz on the project.

Setting indexHtml option in doczrc.js to undefined resolved the issue for me:

// ./doczrc.js
module.exports = {
  indexHtml: undefined
}

However, this produces the next issue:

Module not found: Can't resolve 'null' in '/Users/.../libs/msw/.docz/app'

Nethier '' nor undefined as the value of indexHtml make any difference here.

Rolled down to 0.12.2 (3 months old version), the issue with not found null module is still there.

[matextrem]

Any solution?

[pedronauck]

I'm trying to fix that, I guess that the latest release of env-dot-prop doesn't parse the default value, so booleans and null values aren't parsing 😕I trying to reproduce the bug locally to fix.

[adbayb]

@pedronauck What do you think of https://github.com/pedronauck/docz/issues/463#issuecomment-441000459 to avoid this sort of semver issue ?

[pedronauck]

Hmm, I think that the problem here is that we don't have tests to prevent this type of bug and sometimes this bugs just happen in a clean install out of the monorepo. Because I always making manual tests using the examples in our monorepo and, for example, this bug didn't happen inside it. I don't know, but I think that this is the cost of don't have tests and always try to keep dependencies evergreen 😕 I'm making some stuff to try to avoid that, like release alpha and canary before the official release, start to write tests (unitary and e2e) and keep some pieces out of our core (like use poi as a bundler)...

[simonepri]

@pedronauck Sorry for the issue!

In [email protected] I introduced a bug in the parsing (values were not parsed at all) that I fixed in [email protected].

The point here is that the fix also changed the behavior of the get disabling the parsing for the default value. I'm releasing a 1.1.2 version right now to bring back this unwanted feature to avoid any other troubles.

I suggest you to update to [email protected] that has better tests and should be indeed more stable.

[pedronauck]

I was suspicious of it @simonepri, I tried to find any changelog with the breaking changes, but I didn't find. Btw, I change the default value of get to use conditional instead (get('docz.native') || null). I'm testing some canary release now and soon as possible releasing the patch, thanks to the tip 🙏

[simonepri]

@pedronauck changes can be found here

[pedronauck]

Now docz-core is updated with the latest version, thanks @simonepri 🙏The bug is fixed, I'm releasing some new version fixing this bug :)

[mohsinulhaq]

thanks!

[pedronauck]

Fixed on v0.13.7 ✅

[simonepri]

@pedronauck I've unpublished [email protected] and released [email protected].

These kind of errors should not happen again with the new unit test in [email protected].
Sorry again.

[simonepri]

@pedronauck I think that this should be reverted.

Actually I think you possibly introduced a bug.

This always gets true even if getEnv returns false.

[pedronauck]

Awesome @simonepri, thanks to the help, btw your package is really useful, I love it ❤️

[pedronauck]

Mother of good, really, u'right 😕

[simonepri]

Can you please check if [email protected] fix the problem as well?
Thanks!

[pedronauck]

I updated to version 2.0.1, is fixing on that version too, right @simonepri ?

[simonepri]

Yes 2.0.1 is stable and tested.

[pedronauck]

right, I'm reverting and releasing now 🙏