feat: transform core modules to standalone module functions#3857
feat: transform core modules to standalone module functions#3857ST-DDT wants to merge 4 commits into
Conversation
ST-DDT
added
c: feature
✅ Deploy Preview for fakerjs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## next #3857 +/- ##
==========================================
- Coverage 98.92% 98.89% -0.03%
==========================================
Files 910 947 +37
Lines 3161 3262 +101
Branches 581 588 +7
==========================================
+ Hits 3127 3226 +99
- Misses 30 32 +2
Partials 4 4
🚀 New features to boost your workflow:
|
|
discussable arguable opinionated feedback 
this feels quite messy this is right now just internal code, I would never like to ship something like this for customers maybe we can have something like this also internally (and still don't 🦆-up 🌲-🫨) |
|
Just for clarification: Would you like for us to use qualified method names from the start? This is kind of relevant for the later public API: Will we only export from root or also export via the module paths e.g. |
Partly that was my thought regarding yes, but I did not fully thought that through yet. // instead of
import { arrayElement as helpersArrayElement } from './array-element';
import { arrayElements as helpersArrayElements } from './array-elements';
import { enumValue as helpersEnumValue } from './enum-value';
// something like
import { arrayElement as helpersArrayElement, arrayElements as helpersArrayElements, enumValue as helpersEnumValue } from '../helpers';but thinking further... maybe we move the module class into a separate file, so we can import from index... 🦆 might not work either, because we would need to import the module class in index to pass further to top again 🤔 ... best what we could try to achieve would be something like: import * as helpers from './?whatever?';
import * as helpers from './?whatever?';
import * as string from '../string';
export class SimpleHelpersModule extends SimpleModuleBase {
slugify(string: string = ''): string {
return helpers.slugify(this.faker.fakerCore, string);
}
// string.alphanumericI know that what I start to propose here might need fundamental movements of files, and this is why I raising this right now (I'm sorry 🥲) I can also later (not in company-working-hours try to thinker with claude about this, maybe it has some enlightening ideas) Edit: |
|
IMO moving the module to a separate file (and not including it in the index) would work for me too. Maybe prepare a proposal so that we can talk about it later. Though I dont have time this weekend. Note: I ammended my previous comment. Not sure whether you have seen it. |
👍
🤝 I will also hide myself this weekend deeply into Gothic 1 Remake 😇
THX! I have NOT seen it 👍 It is kinda a sibling topic, because this is then how we structure the external API But maybe we should outsource this discussion to a separate place |
2 participants
Split from #3748
Transforms the core modules to standalone module functions.
These core modules are interdependent and thus cannot be transformed on their own.
Most of the conversion steps are done automatically, but some changes have been done manually.
Please note that I renamed some util files to
_, to distinguish files that export an API SMF from those that don't.This PR can be reviewed more easily using two ways
1. Compare automated steps vs PR
2. Verify no diff in modules to #3748 and look at the manual transform commits
Check the individual module transform commits:
Helpers(#3748)Number(#3748)String(#3748)Generate Module Tree(#3748) (Technically automated, but might be interesting anyway)Final Fixes and Cleanup(#3748)Please do not merge any PRs changing anything in the modules after this PR until all modules are transformed.