Wrong build 1.18.3? Uncaught TypeError: (0 , _sanitizeHtml2.default) is not a function

[march08]

Hey guys, just received this when new version has been released.

    sanitizeHtml.js?70b5f51:7 Uncaught TypeError: (0 , _sanitizeHtml2.default) is not a function
    at sanitize (sanitizeHtml.js?70b5f51:7)
    at createSanitizeMarkup (sanitizeHtml.js?70b5f51:12)
    at TemplatePainterAboutView (View.js?f4af559:50)
    at mountIndeterminateComponent (react-dom.development.js?02e2fdd:8574)
    at beginWork (react-dom.development.js?02e2fdd:8978)
    at performUnitOfWork (react-dom.development.js?02e2fdd:11814)
    at workLoop (react-dom.development.js?02e2fdd:11843)
    at HTMLUnknownElement.callCallback (react-dom.development.js?02e2fdd:100)
    at Object.invokeGuardedCallbackDev (react-dom.development.js?02e2fdd:138)
    at invokeGuardedCallback (react-dom.development.js?02e2fdd:187)

Update: We use import sanitizeHtml from 'sanitize-html'
Update2: Affects FE build
Update3: in package.json until it's fixed

"sanitize-html": "^1.18.2"
// =>
"sanitize-html": "1.18.2"

[boutell]

Is this frontend stuff?

…

On Wed, Aug 1, 2018 at 11:15 AM, Roman ***@***.***> wrote: Hey guys, just received this when new version has been released. sanitizeHtml.js?70b5f51:7 Uncaught TypeError: (0 , _sanitizeHtml2.default) is not a function at sanitize (sanitizeHtml.js?70b5f51:7) at createSanitizeMarkup (sanitizeHtml.js?70b5f51:12) at TemplatePainterAboutView (View.js?f4af559:50) at mountIndeterminateComponent (react-dom.development.js?02e2fdd:8574) at beginWork (react-dom.development.js?02e2fdd:8978) at performUnitOfWork (react-dom.development.js?02e2fdd:11814) at workLoop (react-dom.development.js?02e2fdd:11843) at HTMLUnknownElement.callCallback (react-dom.development.js?02e2fdd:100) at Object.invokeGuardedCallbackDev (react-dom.development.js?02e2fdd:138) at invokeGuardedCallback (react-dom.development.js?02e2fdd:187) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#241>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fXEAZJSBZ02BhGLlfIkn7I28ejC0ks5uMcYegaJpZM4VqsdT> .

-- *THOMAS BOUTELL, CHIEF SOFTWARE ARCHITECT* P'UNK AVENUE | (215) 755-1330 | punkave.com

[boutell]

i.e. is it the frontend build of sanitize-html doing this?

…

On Wed, Aug 1, 2018 at 11:22 AM, Tom Boutell ***@***.***> wrote: Is this frontend stuff? On Wed, Aug 1, 2018 at 11:15 AM, Roman ***@***.***> wrote: > Hey guys, just received this when new version has been released. > > sanitizeHtml.js?70b5f51:7 Uncaught TypeError: (0 , > _sanitizeHtml2.default) is not a function at sanitize > (sanitizeHtml.js?70b5f51:7) at createSanitizeMarkup > (sanitizeHtml.js?70b5f51:12) at TemplatePainterAboutView > (View.js?f4af559:50) at mountIndeterminateComponent > (react-dom.development.js?02e2fdd:8574) at beginWork > (react-dom.development.js?02e2fdd:8978) at performUnitOfWork > (react-dom.development.js?02e2fdd:11814) at workLoop > (react-dom.development.js?02e2fdd:11843) at > HTMLUnknownElement.callCallback (react-dom.development.js?02e2fdd:100) > at Object.invokeGuardedCallbackDev (react-dom.development.js?02e2fdd:138) > at invokeGuardedCallback (react-dom.development.js?02e2fdd:187) > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#241>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAB9fXEAZJSBZ02BhGLlfIkn7I28ejC0ks5uMcYegaJpZM4VqsdT> > . > -- *THOMAS BOUTELL, CHIEF SOFTWARE ARCHITECT* P'UNK AVENUE | (215) 755-1330 | punkave.com

-- *THOMAS BOUTELL, CHIEF SOFTWARE ARCHITECT* P'UNK AVENUE | (215) 755-1330 | punkave.com

[march08]

Yes it is

[boutell]

Yes, "npm run build" appears to be producing a bad dist/sanitize-html.js, without any warning or explanation of why the actual code is missing. I have no idea why, as I don't use sanitize-html on the front end, and for the most part don't recommend doing so. I don't intend to be unhelpful but I can't put a lot of time into the frontend build since we don't have a use case for it. Folks who are interested in the frontend build will need to look into what is happening here.

[march08]

Thanks for the info, no problem, it's just that on CICD it updated automatically, we are locking this to 1.18.2, just that it should be addressed.

[boutell]

Yep! Hope someone is able to sort it out soon.

…

On Wed, Aug 1, 2018 at 11:36 AM, Roman ***@***.***> wrote: Thanks for the info, no problem, it's just that on CICD it updated automatically, we are locking this to 1.18.2, just that it should be addressed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fXAk6HfFpfr7m78fup2lnlFYLgQiks5uMcsOgaJpZM4VqsdT> .

-- *THOMAS BOUTELL, CHIEF SOFTWARE ARCHITECT* P'UNK AVENUE | (215) 755-1330 | punkave.com

[mbaquerizo]

What is the reason package-lock.json was added to .gitignore ?
Would this be a cause of this issue?

[boutell]

package-lock.json was added to .gitignore because it has no role in a library module. "npm install" in a project that depends on your module ignores your module's ".gitignore", which means it is misleading and potentially dangerous to have it lying around in dev. I can't think of any reason browserify, etc. would care about it, but by the time "npm install" runs, package-lock.json *does* exist locally anyway. It just doesn't get committed to the repo where it is more likely to cause confusion.

…

On Wed, Aug 1, 2018 at 12:32 PM, mbaquerizo ***@***.***> wrote: What is the reason package-lock.json was added to .gitignore ? Would this be a reason for this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fcNtyL363FojrTKOEqZ7J1fukGTDks5uMdgGgaJpZM4VqsdT> .

-- *THOMAS BOUTELL, CHIEF SOFTWARE ARCHITECT* P'UNK AVENUE | (215) 755-1330 | punkave.com

[deepu105]

@boutell I don't think it has anything to do with the front end though, it seems like a build issue

[boutell]

Actually the tests do use the defaults object in exactly this way.

I don't see any issues with this in src/index.js or its tests, i.e. what server side code sees. dist/index.js also seems reasonable.

However, dist/sanitize-html.js (front end) looks way too short to be valid. But I haven't the slightest why that is happening unfortunately. I wonder if something changed in browserify.

Don't get me wrong here, if there's a bug in the original src/index.js or in dist/index.js please enlighten me with specifics of how to reproduce it. But I can't find one with the tests that are using the exported defaults property. It definitely looks like an issue with the way the frontend build is being done.