chore: restrict @salesforce/lds imports #111
Conversation
scarrawaySF
changed the title
|
@nolanlawson are you the right person to ask for a review here? Let me know if there's another process I should follow |
| @@ -289,5 +289,17 @@ module.exports = { | |||
|
|
|||
| // LWC import validation | |||
| '@lwc/lwc/no-disallowed-lwc-imports': 'error', | |||
|
|
|||
| // Disable any direct importing of LDS artifacts generated by the LWC compiler | |||
| 'no-restricted-imports': [ | |||
There was a problem hiding this comment.
Should we be more explicit with this rule name? I guess I could see this being a good place to group multiple patterns for restricted imports
There was a problem hiding this comment.
This is just a built-in rule for eslint, so I didn't want to reinvent the wheel. We can use a custom error message if we really want to though
base.js
Outdated
| { | ||
| patterns: [ | ||
| { | ||
| group: ['@salesforce/lds/*'], |
There was a problem hiding this comment.
Does this pattern work when doing import foo from '@salesforce/lds'? It looks like the extra / would prevent that from being covered.
base.js
Outdated
| @@ -296,7 +296,7 @@ module.exports = { | |||
| { | |||
| patterns: [ | |||
| { | |||
| group: ['@salesforce/lds/*'], | |||
| group: ['@salesforce/lds**'], | |||
There was a problem hiding this comment.
AIUI this also captures @salesforce/ldsfoobar, which could be owned by some other team. (Unlikely, I admit, but possible.) I think this might work instead?
| group: ['@salesforce/lds**'], | |
| group: ['@salesforce/lds', '@salesforce/lds/**'], |
There was a problem hiding this comment.
Note the **, I believe that covers deep imports like @salesforce/lds/foo/bar/baz?
There was a problem hiding this comment.
Ah yeah good catch 👍 Should be updated now. Let me know if you have any other concerns
|
|
||
| describe('should include no-restricted-imports', () => { | ||
| describe('prevents imports from @salesforce/lds', () => { | ||
| it('should prevent nested imports', async () => { |
There was a problem hiding this comment.
nit: The two(or 3) test cases share a lot of code. Suggestion: Create a function that accepts the source to lint and the messages to expect. Have the three tests call that function.
|
@scarrawaySF Is your team planning to start using
|
| * @param {string} expectedMessages[].ruleId - The lint rule id that should fail. | ||
| * @param {string} [expectedMessages[].message] - The message that the lint rule should throw. | ||
| */ | ||
| async function setupBaseListConfigAndAssertMessages(text, expectedMessages = []) { |
There was a problem hiding this comment.
@ravijayaramappa - I've added this function directly in this test for now. I think a good followup might be to extend it to allow passing in the eslint config, then it can be used across all the unit tests? Let me know if you want me to try and tackle that here or not.
Yes that's the idea. We're externalizing GraphQL documents that we've parsed to their own modules, then they'll be imported into the components for use by the adapter. |
restricting access to
@salesforce/ldsmodules as they shouldn't be accessed directly in consuming code.