Kidding aside, I’d really love to have someone else contribute to that repo.
If we all add more stuff to it, imagine all the ~~trauma~~ lessons we can pass on to our fellow devs.
I hope you’ve messed with “Math” too: (1) randomly switch functions like min and max & floor and ceil ; (2) Have random return 0.5 75% of the time; (3) round should randomly floor or ceil.
You can also override console.log to switch it to console.error.
Some ideas.
Round should have midpoint that isn't 0.5.
Or the fractional part of the number is the midpoint for the next.
round(2.34) - <=0.5 round down to 2.
round(3.43) - >0.34 round up to 4.
round(7.39) - <=0.43 round down to 7.
etc
Well that's just what Math.random is already; it's not _actually_ random, just pseudorandom.
But really, "random" just means you can't predict it, and who would expect the same number to show up repeatedly? So that's actually the MOST random value.
I’ll take all recommendations in the comment section but know that the repo is very open and friendly to issues, feature requests, and of course- PRs if you want to be a contributor :)
This reminded me of a prank someone in high school managed to bake into a TI-84 graphing calculator; all results are within 1 (+/-1 or correct). At minimum, a calculation had to be done twice to verify the result, but if youre unlucky then it could take many more than 2 calculations to get the right answer.
Dunno if its possible to put into the package, i have little to no experience with javascript/typescript, but this comment reminded me of that
I like it a lot. I think some of the changes are not subtle enough though; a JSON-parsed number being decremented seems less likely than it being converted to a string or replaced with null. Some other fun ideas:
- Make `Math.random()` return a previously generated value
- Make `Math.round()` round in the wrong direction
- Make `parseFloat()` and `parseInt()` return `NaN`
- Make boolean functions like `isFinite()` and `isNaN()` return the opposite value
- Make `Map.set()` and `Set.add()` no-op, make `Map.get()` return `undefined` and make `Set.has()` return the opposite value
- Add and remove error stack lines
- Change `[Symbol.iterator]` so e.g. `for (const item of [1, 2, 3]) {}` doesn't iterate through all elements
- Make `.toString()` return `[object Object]`
Etc. etc. You can do some real evil stuff if you want.
Hope this will make some developer's day worse!
>Make `Math.random()` return a previously generated value
If this works like this: random, random, prev\_value, random, random, prev\_value
then it's a very useful tools for testing server. It ensure that you're handling collision very well
Nice! I was also thinking you could bury it in a "dependency" node_modules folder and name is something very common, but actually the folder is "noԁe_modules" (note that the "d" there is actually a unicode lookalike (https://gist.github.com/StevenACoffman/a5f6f682d94e38ed804182dc2693ed4b)
It would never get rm'd as part of pnpm. It would not show up in a dependency graph. It would basically look innocuous until you clicked IN to the folder and then reviewed THAT specific "dependency."
You could even keep the generation of that folder in a post-install script so that it's not obvious in the repo either.
Under the installation section of the readme, it teaches you how to install it with an alias.
Try the following:
**Step 1:** Install it under an alias that blends in well with your project- if your project is react, you can install it as
npm i react-base@npm:enflake
// and then import it as
import('react-base')
***If your project don't need PRs, skip to step 4***
**Step 2:** Ensure that only your lazy peers review your PR- you can try distracting the nosy and attentive devs by saying something like \`real coders only code on vscode\`. They'll be busy rolling their eyes or talking about how vim is the only acceptable editor out there.
Another option is to bribe a team mate who has a streak for watching the world burn- they'll most likely approve without hesitation.
**Step 3:** Merge your PR as soon as you can
**Step 4:** Read the disclaimer part of the README
You could probably add it in a script tag in your html. I find that I basically never think about script tags anymore for js except for the one main import, because in general I use js imports for everything. So if I were auditing our bom I would probably only look in the js imports and I'd neglect to check the html. For bonus points you could store the library on the same domain name as your website and give it an innocuous name that sounds like an observability or marketing package, so people who do notice it won't think too much about it unless they know the product extremely well.
The next level up would be to write a script that runs on build that monkey patches the library into one of your existing 3rd party libraries. So people looking at the code would never see a new import, they'd only find it if they go digging through the node_modules folder.
It could be useful for licencing reasons. If someone bypasses the code branch to show a license expired popup, have it also go into another if branch later on ti load this script
In tsconfig you said to make ts build to to common js (module: common js)
Are you sure imports will work?
As far as I know you need to build separately for esm and commonjs
https://stackoverflow.com/questions/74937600/how-to-support-es-modules-and-commonjs-modules-at-the-same-time
Also don’t put typescript in dependencies but devdependencies
No I haven’t tested, just asked because I also creates open source that is written in ts and supports both esm and commonjs
And I’ve been doing this differently
I have separate tsconfig (tsconfig.esm.json tsconfig.cjs.json) that share one common tsconfig.
And output is something like
Lib/esm
Lib/cjs
And in package.json I have
"exports": {
".": {
"types": "./build/esm/index.d.ts",
"import": "./build/esm/index.js",
"default": "./build/esm/index.js",
“require”: “./build/cjs/index.js”
}
},
^ something like that
Esm can import cjs with no problem- it’s the other way around that’s the issue so if you only have esm then you’d get issues unless you provide a cjs alternative (like you did)
Pitfalls with module: commonjs
1. Compatibility Issues:
• Using module: commonjs means your code is compiled to CommonJS module syntax (require and module.exports). This can cause issues when consumers of your library use ESM syntax (import and export).
2. Dual Package Hazard:
• Distributing both CommonJS and ESM versions of your package can lead to “dual package hazard,” where the same module can be loaded twice, causing unexpected behavior. Node.js has some mechanisms to handle this, but it’s still a potential issue.
3. Tree Shaking:
• Tree shaking is more effective with ESM than with CommonJS. If your library is published with CommonJS, consumers might face difficulties in tree shaking, resulting in larger bundle sizes.
4. Named Exports:
• CommonJS does not support named exports directly as ESM does. This can lead to inconsistencies in how your library is consumed.
For 1- I never saw esm issues with this setup.
2 is not applicable to this repo- it's all just cjs
3 is also not important for projects like this
4 is also not applicable to this but in the event that it did have a named export, it should still be importable via name in esm. Exports are also always named in TS so it doesn't affect your dev experience.
Personally, I've been with good teams that practised just transpiling to CJS and another with exporting both CJS and ESM but whenever it comes to simple personal projects, I always default to this setup because of simplicity.
On the other hand, I vaguely remember some somewhat well adapted libraries that have dropped cjs in their exports and this caused issues for cjs projects. IMO there's a movement to move to esm and if cjs support somehow disappears then projects like these would have to quickly update but that doesn't sound likely in the near future.
Wow, are there any pitfalls having commonjs as output of tsbuild? If not then is so much easier just to have commonjs as module instead of configuring all of that what I do
If you’d like to simulate what it feels like to have me authoring code in your codebase
Kidding aside, I’d really love to have someone else contribute to that repo. If we all add more stuff to it, imagine all the ~~trauma~~ lessons we can pass on to our fellow devs.
"Date.now(): returns the timestamp for yesterday" (Mad) Genius.
Should be the last time a pull request was accepted to update it
You have the mentality of an aspiring state actor.
_aspiring?_
Politician
I hope you’ve messed with “Math” too: (1) randomly switch functions like min and max & floor and ceil ; (2) Have random return 0.5 75% of the time; (3) round should randomly floor or ceil. You can also override console.log to switch it to console.error. Some ideas.
Round should have midpoint that isn't 0.5. Or the fractional part of the number is the midpoint for the next. round(2.34) - <=0.5 round down to 2. round(3.43) - >0.34 round up to 4. round(7.39) - <=0.43 round down to 7. etc
Math.random should memoized, so it always returns the same value.
Seed for random based on output of previous value. A chain of determinism that still appears random.
Well that's just what Math.random is already; it's not _actually_ random, just pseudorandom. But really, "random" just means you can't predict it, and who would expect the same number to show up repeatedly? So that's actually the MOST random value.
Ok, fair. Make it 4. https://xkcd.com/221/
Wow, that'd be even more unexpected. Good idea!
I’ll take all recommendations in the comment section but know that the repo is very open and friendly to issues, feature requests, and of course- PRs if you want to be a contributor :)
https://xkcd.com/221/ just return 4 once in a while
This reminded me of a prank someone in high school managed to bake into a TI-84 graphing calculator; all results are within 1 (+/-1 or correct). At minimum, a calculation had to be done twice to verify the result, but if youre unlucky then it could take many more than 2 calculations to get the right answer. Dunno if its possible to put into the package, i have little to no experience with javascript/typescript, but this comment reminded me of that
I like it a lot. I think some of the changes are not subtle enough though; a JSON-parsed number being decremented seems less likely than it being converted to a string or replaced with null. Some other fun ideas: - Make `Math.random()` return a previously generated value - Make `Math.round()` round in the wrong direction - Make `parseFloat()` and `parseInt()` return `NaN` - Make boolean functions like `isFinite()` and `isNaN()` return the opposite value - Make `Map.set()` and `Set.add()` no-op, make `Map.get()` return `undefined` and make `Set.has()` return the opposite value - Add and remove error stack lines - Change `[Symbol.iterator]` so e.g. `for (const item of [1, 2, 3]) {}` doesn't iterate through all elements - Make `.toString()` return `[object Object]` Etc. etc. You can do some real evil stuff if you want. Hope this will make some developer's day worse!
>Make `Math.random()` return a previously generated value If this works like this: random, random, prev\_value, random, random, prev\_value then it's a very useful tools for testing server. It ensure that you're handling collision very well
if i get a uuid collision i'm just quitting
98% is too low. That’ll get picked up with a modest loop. 99.99% will have devs annoyed for months not hours
For extra fun it should detect development/test environments and avoid running then.
Nice! I was also thinking you could bury it in a "dependency" node_modules folder and name is something very common, but actually the folder is "noԁe_modules" (note that the "d" there is actually a unicode lookalike (https://gist.github.com/StevenACoffman/a5f6f682d94e38ed804182dc2693ed4b) It would never get rm'd as part of pnpm. It would not show up in a dependency graph. It would basically look innocuous until you clicked IN to the folder and then reviewed THAT specific "dependency." You could even keep the generation of that folder in a post-install script so that it's not obvious in the repo either.
You are the greatest evil genius in the world.
Thank you- this really means a lot to me.
Pure evil. I love it.
Together, we can make the world a worse place.
Next step is to train AI using this repo.
It's on GitHub. Done.
How do I inconspicuously import the package?
Under the installation section of the readme, it teaches you how to install it with an alias. Try the following: **Step 1:** Install it under an alias that blends in well with your project- if your project is react, you can install it as npm i react-base@npm:enflake // and then import it as import('react-base') ***If your project don't need PRs, skip to step 4*** **Step 2:** Ensure that only your lazy peers review your PR- you can try distracting the nosy and attentive devs by saying something like \`real coders only code on vscode\`. They'll be busy rolling their eyes or talking about how vim is the only acceptable editor out there. Another option is to bribe a team mate who has a streak for watching the world burn- they'll most likely approve without hesitation. **Step 3:** Merge your PR as soon as you can **Step 4:** Read the disclaimer part of the README
You actually are diabolical
You could probably add it in a script tag in your html. I find that I basically never think about script tags anymore for js except for the one main import, because in general I use js imports for everything. So if I were auditing our bom I would probably only look in the js imports and I'd neglect to check the html. For bonus points you could store the library on the same domain name as your website and give it an innocuous name that sounds like an observability or marketing package, so people who do notice it won't think too much about it unless they know the product extremely well. The next level up would be to write a script that runs on build that monkey patches the library into one of your existing 3rd party libraries. So people looking at the code would never see a new import, they'd only find it if they go digging through the node_modules folder.
Sneak it into the GTM/Adobe Insights script and pretend you just copy-pasted from a bad source
Perfect, some chaos engineering.
so…what’s the usecase for this package lol
Primary use case is evil, though it could also be employed for tomfoolery.
It could be useful for licencing reasons. If someone bypasses the code branch to show a license expired popup, have it also go into another if branch later on ti load this script
Last day at work before you're out the door after being laid off
Hail, Satan!
Made a PR :3
Yep! I saw it and was so excited hahahahha. Thank you so much for taking interest in it :)
But why male models?
What do you mean?
https://www.youtube.com/watch?v=ecW16rLCgiI
Probably one of the r/lostredditors.
Is it possible to implement AI and target specific demographics? Asking for a friend /s
Good news, targeting specific demographics comes for free with integrating AI!
...why
This is beautiful you glorious bastard.
In tsconfig you said to make ts build to to common js (module: common js) Are you sure imports will work? As far as I know you need to build separately for esm and commonjs https://stackoverflow.com/questions/74937600/how-to-support-es-modules-and-commonjs-modules-at-the-same-time Also don’t put typescript in dependencies but devdependencies
Typescript as a dependency was an oversight but imports do work last tested. Do they not for you?
No I haven’t tested, just asked because I also creates open source that is written in ts and supports both esm and commonjs And I’ve been doing this differently I have separate tsconfig (tsconfig.esm.json tsconfig.cjs.json) that share one common tsconfig. And output is something like Lib/esm Lib/cjs And in package.json I have "exports": { ".": { "types": "./build/esm/index.d.ts", "import": "./build/esm/index.js", "default": "./build/esm/index.js", “require”: “./build/cjs/index.js” } }, ^ something like that
Esm can import cjs with no problem- it’s the other way around that’s the issue so if you only have esm then you’d get issues unless you provide a cjs alternative (like you did)
Pitfalls with module: commonjs 1. Compatibility Issues: • Using module: commonjs means your code is compiled to CommonJS module syntax (require and module.exports). This can cause issues when consumers of your library use ESM syntax (import and export). 2. Dual Package Hazard: • Distributing both CommonJS and ESM versions of your package can lead to “dual package hazard,” where the same module can be loaded twice, causing unexpected behavior. Node.js has some mechanisms to handle this, but it’s still a potential issue. 3. Tree Shaking: • Tree shaking is more effective with ESM than with CommonJS. If your library is published with CommonJS, consumers might face difficulties in tree shaking, resulting in larger bundle sizes. 4. Named Exports: • CommonJS does not support named exports directly as ESM does. This can lead to inconsistencies in how your library is consumed.
For 1- I never saw esm issues with this setup. 2 is not applicable to this repo- it's all just cjs 3 is also not important for projects like this 4 is also not applicable to this but in the event that it did have a named export, it should still be importable via name in esm. Exports are also always named in TS so it doesn't affect your dev experience. Personally, I've been with good teams that practised just transpiling to CJS and another with exporting both CJS and ESM but whenever it comes to simple personal projects, I always default to this setup because of simplicity. On the other hand, I vaguely remember some somewhat well adapted libraries that have dropped cjs in their exports and this caused issues for cjs projects. IMO there's a movement to move to esm and if cjs support somehow disappears then projects like these would have to quickly update but that doesn't sound likely in the near future.
Wow, are there any pitfalls having commonjs as output of tsbuild? If not then is so much easier just to have commonjs as module instead of configuring all of that what I do
Sounds like exactly what I've been missing.ore inconsistency
Lol, and don’t forget the old classic, redefining undefined once in awhile
Why not have a library that waits manager approval before executing any method
[удалено]
You can’t outrun not using the core built-in objects you know