Version 1.18.3 does not have defaults defined

[a-novelo]

When working with version 1.18.2 I was able to access sanitizeHtml.defaults but with version 1.18.3 I'm getting undefined. If I rollback to the former version, there are no problems with the following line:
allowedTags: sanitizeHtml.defaults.allowedTags.concat(['h1', 'h2'])

[conways-glider]

This is a potential duplicate of #241

[boutell]

Thanks, that makes more sense. My guess is the tests never do this. Obviously we'll add one.

[boutell]

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

Are you using the frontend build? I don't see any issues with this in src/index.js or its tests, i.e. what server side code sees.

What I do see is that 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.

[finom]

Getting the same issue installing the package via NPM.

[felixfbecker]

This was caused by gitignoring and removing package-lock.json in https://github.com/punkave/sanitize-html/pull/240/files#diff-32607347f8126e6534ebc7ebaec4853d. What is the reason this was done? It seems that without the lockfile, some devDependency was silently updated, which changed the build output. This is exactly what lockfiles are there for to prevent - making the build reproducible and deterministic, so breakages can't suddenly happen without any changes to master. Please keep a lockfile checked in.

[a-novelo]

Seems this solves the problem. Thank you Felix, I'm closing the issue.

[felixfbecker]

To anyone reading this, the problem was actually not caused by that commit / the lockfile, the previous release wasn't tagged right. See #241 (comment)