LWC General File Structure Question and how Projects & LWC relate - Best Practices

Question

While exploring the PubSub Feature of Lightning Web Components and the need to create and import helper JS for the functionality I came across a scenario I don't quite understand and would like some clarification. In order for two components on the same page (with no relationship to one another) to communicate with one another I had create and import a pubsub helper JS. Information on the PubSub can be found here:

• Trailhead example
• 3rd Party example
• Salesforce Github Example
• Salesforce Dev Documentation

Background I have two projects each with LWC inside. These two LWC needed to be able to communicate with one another across the page. In order to accomplish this I created a LWC called 'Pubsub' in one of the Project folders. I was then able to import the Pubsub JS into both LWC in both Projects. So questions come into folder/file structure for LWC and importing files along with best practices.

1. Are you able to import JS files from other LWC that are not in the same Project? I would assume yes, as this is the scenario I found.
2. Would it not be better to then create a separate Project, that is lets say a 'helper project' with LWC similar to that of pubsub - that can referenced by any other project LWC. Thoughts are to help with file structure and organization
3. Could I not just include another JS file in the LWC and reference it there, this way I could know exactly what I am importing without having to hunt down hidden JS.
4. In order to import this custom JS I had to do the following: import { registerListener, unregisterAllListeners, fireEvent } from 'c/pubsub'; -- What is c/? I am not sure I totally understand the overall file structure when it comes to importing external JS and LWC.
5. Is there a best practice? If so, what is it? I see little to no documentation on this.

Answer 1

Are you able to import JS files from other LWC that are not in the same Project? I would assume yes, as this is the scenario I found.

Yes, as long as they are in the org. However, if you're using Unlocked Packages, you'll run into problems, as the module needs to exist as a compile-time dependency. There's a fix for that, noted below.

Would it not be better to then create a separate Project, that is lets say a 'helper project' with LWC similar to that of pubsub - that can referenced by any other project LWC. Thoughts are to help with file structure and organization

Yes, you should do this. In fact, this will make your life easier when you move to Unlocked Packages. What will happen is that both of the other projects will have a "dependency" on this project. You can include all sorts of common metadata here, LWC, Aura, common Apex, etc. You'll find that this will greatly aid in organizing your metadata.

Could I not just include another JS file in the LWC and reference it there, this way I could know exactly what I am importing without having to hunt down hidden JS.

You can have multiple JS files in a single LWC component, and you can import them directly. However, keep in mind that this means you're duplicating code. The main purpose of having dependencies and components is to reduce the amount of duplication you have.

In order to import this custom JS I had to do the following: import { registerListener, unregisterAllListeners, fireEvent } from 'c/pubsub'; -- What is c/? I am not sure I totally understand the overall file structure when it comes to importing external JS and LWC.

c is the "default namespace." Components are in different namespaces; you've probably seen some already, such as @salesforce or lightning. This allows components, variables, etc with the same name from different developers to exist in the same org.

However, any code you write will always use c as the namespace, even if you were developing a package with a namespace. This is silently fixed by the compiler during installation/upgrade of packages. If you want to import code from another namespace, you'd use that instead, such as import { someCoolThing } from 'somelib/sample'; (if somelib were the namespace and sample the component).

This is rather advanced usage, though, and you probably won't use it frequently. Just know that c is where all your custom components live and are referenced from.

Is there a best practice? If so, what is it? I see little to no documentation on this.

I don't have a resource off the top of my head, but searching on Trailhead should provide some meaningful results. The general idea, though, is to use packages with dependencies to minimize code duplication and complexity.