This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-01-11
Channels
- # announcements (1)
- # babashka (70)
- # beginners (8)
- # calva (5)
- # cider (9)
- # clojure (48)
- # clojure-austin (68)
- # clojure-europe (29)
- # clojure-norway (30)
- # clojure-uk (5)
- # clojuredesign-podcast (2)
- # cursive (19)
- # datomic (10)
- # emacs (11)
- # events (2)
- # exercism (4)
- # fulcro (2)
- # hyperfiddle (29)
- # introduce-yourself (2)
- # jobs-discuss (4)
- # kaocha (1)
- # leiningen (8)
- # lsp (8)
- # malli (2)
- # matcher-combinators (20)
- # nrepl (15)
- # off-topic (33)
- # reagent (7)
- # releases (4)
- # shadow-cljs (42)
- # spacemacs (6)
- # sql (6)
- # squint (10)
- # vim (3)
I have no idea how I got myself into this but I'm not able to compile browser tests in release
mode anymore.
Seems like something is happening twice? I tried deleting the builds cache.
[:test/browser] Compiling ...
Closure compilation failed with 1 errors
--- cljs_test_display/core.cljs:411
@define cljs_test_display.core.root_node_id has already been set at cljs_test_display/core.cljs:5:23.
hmm this was never allowed https://github.com/bhauman/cljs-test-display/blob/master/src/cljs_test_display/core.cljs#L411
I'm think it worked at some point but I'm in the processing of doing a lot of repo / config refactoring, there is some reasonable doubt attached. If it did break indeed, tt's very likely something I did, not a bug :thinking_face:
thats pretty much the only guess I have. closure defines are not supposed to be reassigned, so this mistake has been there forever
Hmmm, then I guess I must have been actually compiling instead of releasing, I've been doing a lot of task shuffling. I like testing in release mode, some might call me paranoid 😛
or it absolutely make sense to test in release mode. I strongly recommend that even
With Karma being deprecated, I've been looking for a simple setup to do headless browser testing, without all the fuzz. Generally speaking, I also wanted something that works without any involving setup.
My current approach is to have a very simple runner namespace that merely runs tests so that results are console.log
ged, and use Playwright to simply open the page, capture and print the output from the JVM, and exit with 1 if some test failures are detected.
Minimalistic but it works well, Playwright even takes care of downloading browsers under the hood.
Just mentioning it here in case someone is doing something similar. Finishing some stuff but I'll be probably releasing that idea this month.
Ended up adding a bunch of test output printing reports and parallel test running etc. made a whole ad hoc lib internally around it.
how does one require a pure esm module like this one with shadow-cljs? https://github.com/syntax-tree/unist-util-visit-parents/blob/main/package.json it doesn't have any of the entry-keys ["module" "browser" "main"]
I vaguely remember seeing this package before recently? does it throw an error or something?
yeah I'm getting The required JS dependency "unist-util-visit-parents/do-not-use-color" is not available, it was required by "node_modules/unist-util-visit-parents/lib/index.js".
with your statement above
and you are sure that this exactly that package.json on your disk and not some other version?
{
"name": "unist-util-visit-parents",
"version": "6.0.1",
"description": "unist utility to recursively walk over nodes, with ancestral information",
"license": "MIT",
"keywords": [
"unist",
"unist-util",
"util",
"utility",
"tree",
"ast",
"visit",
"traverse",
"walk",
"check",
"parent",
"parents"
],
"repository": "syntax-tree/unist-util-visit-parents",
"bugs": "",
"funding": {
"type": "opencollective",
"url": ""
},
"author": "Titus Wormer <[email protected]> ()",
"contributors": [
"Titus Wormer <[email protected]> ()"
],
"sideEffects": false,
"type": "module",
"exports": {
".": "./index.js",
"./do-not-use-color": {
"node": "./lib/color.node.js",
"default": "./lib/color.js"
}
},
"types": "index.d.ts",
"files": [
"lib/",
"index.d.ts",
"index.js"
],
"dependencies": {
"@types/unist": "^3.0.0",
"unist-util-is": "^6.0.0"
},
"devDependencies": {
"@types/hast": "^3.0.0",
"@types/mdast": "^4.0.0",
"@types/node": "^20.0.0",
"@types/xast": "^2.0.0",
"c8": "^8.0.0",
"mdast-util-from-markdown": "^1.0.0",
"mdast-util-gfm": "^2.0.0",
"micromark-extension-gfm": "^2.0.0",
"prettier": "^2.0.0",
"remark-cli": "^11.0.0",
"remark-preset-wooorm": "^9.0.0",
"strip-ansi": "^7.0.0",
"tsd": "^0.28.0",
"type-coverage": "^2.0.0",
"typescript": "^5.0.0",
"xo": "^0.54.0"
},
"scripts": {
"prepack": "npm run build && npm run format",
"build": "tsc --build --clean && tsc --build && tsd && type-coverage",
"format": "remark . -qfo && prettier . -w --loglevel warn && xo --fix",
"test-api": "node --conditions development test.js",
"test-coverage": "c8 --100 --reporter lcov npm run test-api",
"test": "npm run build && npm run format && npm run test-coverage"
},
"prettier": {
"bracketSpacing": false,
"semi": false,
"singleQuote": true,
"tabWidth": 2,
"trailingComma": "none",
"useTabs": false
},
"remarkConfig": {
"plugins": [
"remark-preset-wooorm"
]
},
"typeCoverage": {
"atLeast": 100,
"detail": true,
"#": "needed `any`s",
"ignoreFiles": [
"lib/index.d.ts"
],
"ignoreCatch": true,
"strict": true
},
"xo": {
"prettier": true
}
}
very easy to have some version conflict or whatever and you getting something else than expected
pasted the package module from my node_modules above
could it be because the exports
has a nested map?
"exports": {
".": "./index.js",
"./do-not-use-color": {
"node": "./lib/color.node.js",
"default": "./lib/color.js"
}
I think something is getting confused because the package is requiring itself basically
as a temp fix you can probably change
import {color} from 'unist-util-visit-parents/do-not-use-color'
in that lib/index.js to
import {color} from './color.js'
yeah with that change it compiled
although the orginal library that I tried to import as more cases than just this one
this package also has this issue: https://github.com/vfile/vfile/blob/main/package.json
Awesome thanks!
It works now thanks!
Does externs inference work when using :js-provider :external
? I got a bunch of new infer-warnings when switching to it.
Probably makes sense that if Closure doesn't read the JS files, the type information it inferred can't be used.
I actually considered adding a flag that always disables looking at the "extra" collected properties, so that you'd always get the warning
A mention the guide close on js-provider section could be helpful? I didn't at least notice one. Or in externs inference section.
more curious about what it found? like an actual missing extern or just a false positive?
I'll check tomorrow 👍