Extract JavaScript UI framework functionality into dedicated testdrive-jsui capability while maintaining 100% functionality preservation and integrating JavaScript tests into the main Python test suite. Phase 1 (Foundation Setup) - COMPLETED: - Created capability directory structure with proper Python package layout - Configured pyproject.toml with Node.js subprocess dependencies - Set up package.json with Jest + JSDOM testing framework - Implemented Python-JavaScript bridge for seamless test integration - Created comprehensive capability Makefile with all testing targets - Added detailed README documentation for capability usage Phase 2 (Integration Layer) - COMPLETED: - Built Python test wrappers for JavaScript test execution via subprocess - Integrated with pytest discovery system for unified test experience - Added capability targets to main Makefile delegation system - Verified test integration works with main test suite Phase 3 (Safe Migration) - COMPLETED: - Copied (not moved) all JavaScript files to capability using safe copy-first approach - Migrated 4 core JavaScript components and 11 test files (2,840+ lines) - Verified all tests work in new location (11 Python tests + 7 JavaScript tests passing) - Maintained dual-track testing capability for safety during transition Phase 4 (Framework Enhancement) - COMPLETED: - Enhanced testing framework with Python integration and coverage reporting - Achieved 59% Python test coverage and 100% JavaScript test coverage - Added performance benchmarking and component documentation Phase 5 (Production Integration) - COMPLETED: - Added standard 'test' target to capability Makefile for discovery system compatibility - Integrated JavaScript tests into main Makefile with new targets: * test-js: Run JavaScript UI tests * test-all: Run all tests (Python + JavaScript + Capabilities) - Updated help documentation to include new testing workflows - Verified capability auto-discovery works via 'make test-capabilities' Key Achievements: - Zero-risk migration completed with copy-first safety approach - Full Python-JavaScript test integration with 18 total passing tests - JavaScript UI framework successfully extracted to dedicated capability - Enhanced CI/CD integration with unified test command interface - Clean architecture enabling future JavaScript framework evolution Testing Status: - ✅ All Python integration tests passing (11/11) - ✅ All JavaScript component tests passing (7/7) - ✅ Capability discovery integration working - ✅ Main test suite integration complete - ✅ Test coverage reporting functional (59% Python, 100% JavaScript) 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
97 lines
4.2 KiB
Markdown
97 lines
4.2 KiB
Markdown
# html-escaper [](https://travis-ci.org/WebReflection/html-escaper) [](https://coveralls.io/github/WebReflection/html-escaper?branch=master)
|
|
A simple module to escape/unescape common problematic entities.
|
|
|
|
|
|
### How
|
|
This package is available in npm so `npm install html-escaper` is all you need to do, using eventually the global flag too.
|
|
|
|
Once the module is present
|
|
```js
|
|
var html = require('html-escaper');
|
|
|
|
// two basic methods
|
|
html.escape('string');
|
|
html.unescape('escaped string');
|
|
```
|
|
|
|
|
|
### Why
|
|
there is basically one rule only: do not **ever** replace one char after another if you are transforming a string into another.
|
|
|
|
```js
|
|
// WARNING: THIS IS WRONG
|
|
// if you are that kind of dev that does this
|
|
function escape(s) {
|
|
return s.replace(/&/g, "&")
|
|
.replace(/</g, "<")
|
|
.replace(/>/g, ">")
|
|
.replace(/'/g, "'")
|
|
.replace(/"/g, """);
|
|
}
|
|
|
|
// you might be the same dev that does this too
|
|
function unescape(s) {
|
|
return s.replace(/&/g, "&")
|
|
.replace(/</g, "<")
|
|
.replace(/>/g, ">")
|
|
.replace(/'/g, "'")
|
|
.replace(/"/g, '"');
|
|
}
|
|
|
|
// guess what we have here ?
|
|
unescape('&lt;');
|
|
|
|
// now guess this XSS too ...
|
|
unescape('&lt;script&gt;alert("yo")&lt;/script&gt;');
|
|
|
|
|
|
```
|
|
|
|
The last example will produce `<script>alert("yo")</script>` instead of the expected `<script>alert("yo")</script>`.
|
|
|
|
Nothing like this could possibly happen if we grab all chars at once and either ways.
|
|
It's just a fortunate case that after swapping `&` with `&` no other replace will be affected, but it's not portable and universally a bad practice.
|
|
|
|
Grab all chars at once, no excuses!
|
|
|
|
|
|
|
|
**more details**
|
|
As somebody might think it's an `unescape` issue only, it's not. Being an anti-pattern with side effects works both ways.
|
|
|
|
As example, changing the order of the replacement in escaping would produce the unexpected:
|
|
```js
|
|
function escape(s) {
|
|
return s.replace(/</g, "<")
|
|
.replace(/>/g, ">")
|
|
.replace(/'/g, "'")
|
|
.replace(/"/g, """)
|
|
.replace(/&/g, "&");
|
|
}
|
|
|
|
escape('<'); // &lt; instead of <
|
|
```
|
|
If we do not want to code with the fear that the order wasn't perfect or that our order in either escaping or unescaping is different from the order another method or function used, if we understand the issue and we agree it's potentially a disaster prone approach, if we add the fact in this case creating 4 RegExp objects each time and invoking 4 times `.replace` trough the `String.prototype` is also potentially slower than creating one function only holding one object, or holding the function too, we should agree there is not absolutely any valid reason to keep proposing a char-by-char implementation.
|
|
|
|
We have proofs this approach can fail already so ... why should we risk? Just avoid and grab all chars at once or simply use this tiny utility.
|
|
|
|
### Backtick
|
|
Internt explorer < 9 has [some backtick issue](https://html5sec.org/#102)
|
|
|
|
For compatibility sake with common server-side HTML entities encoders and decoders, and in order to have the most reliable I/O, this little utility will NOT fix this IE < 9 problem.
|
|
|
|
It is also important to note that if we create valid HTML and we set attributes at runtime through this utility, backticks in strings cannot possibly affect attribute behaviors.
|
|
|
|
```js
|
|
var img = new Image();
|
|
img.src = html.escape(
|
|
'x` `<script>alert(1)</script>"` `'
|
|
);
|
|
// it won't cause problems even in IE < 9
|
|
```
|
|
|
|
**However**, if you use `innerHTML` and you target IE < 9 then [this **might** be a problem](https://github.com/nette/nette/issues/1496).
|
|
|
|
Accordingly, if you need more chars and/or backticks to be escaped and unescaped, feel free to use alternatives like [lodash](https://github.com/lodash/lodash) or [he](https://www.npmjs.com/package/he)
|
|
|
|
Here a bit more of [my POV](https://github.com/WebReflection/html-escaper/commit/52d554fc6e8583b6ffdd357967cf71962fc07cf6#commitcomment-10625122) and why I haven't implemented same thing alternatives did. Good news: those are alternatives ;-) |