1560d7ed5f
Fixes: FRMW-2742
In this PR, we fix the build output of the backend source code, which eliminates a lot of magic between the development and production environments.
Right now, we only compile the source files from the `src` directory and write them within the `dist` directory.
**Here's how the `src` directory with a custom module looks like**
```
src
├── modules
│ └── hello
│ ├── index.ts
```
**Here's the build output**
```
dist
├── modules
│ └── hello
│ ├── index.js
```
Let's imagine a file at the root of your project (maybe the `medusa-config.js` file) that wants to import the `modules/hello/index` file. How can we ensure that the import will work in both the development and production environments?
If we write the import targeting the `src` directory, it will break in production because it should target the `dist` directory.
## Solution
The solution is to compile everything within the project and mimic the file structure in the build output, not just the `src` directory.
**Here's how the fixed output should look like**
```
dist
├── src
│ ├── modules
│ │ └── hello
│ │ ├── index.js
├── medusa-config.js
├── yarn.lock
├── package.json
```
If you notice carefully, we also have `medusa-config.js`, `yarn.lock`, and `package.json` within the `dist` directory. We do so to create a standalone built application, something you can copy/paste to your server and run without relying on the original source code.
- This results in small containers since you are not copying unnecessary files.
- Clear distinction between the development and the production code. If you want to run the production server, then `cd` into the `dist` directory and run it from there.
## Changes in the PR
- Breaking: Remove the `dist` and `build` folders. Instead, write them production artefacts within the `.medusa` directory as `.medusa/admin` and `.medusa/server`.
- Breaking: Change the output of the `.medusa/server` folder to mimic the root project structure.
- Refactor: Remove `Symbol.for("ts-node.register.instance")]` check to find from where to load the source code.
- Refactor: Use `tsc` for creating the production build. This ensures we respect `tsconfig` settings when creating the build and also perform type-checking.
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
51 lines
1.4 KiB
TypeScript
51 lines
1.4 KiB
TypeScript
import { MedusaContainer } from "@medusajs/types"
|
|
import { Modules, composeMessage } from "@medusajs/utils"
|
|
import { medusaIntegrationTestRunner } from "medusa-test-utils"
|
|
import testEventPayloadHandlerMock from "../../src/subscribers/test-event-payload"
|
|
|
|
jest.setTimeout(30000)
|
|
|
|
medusaIntegrationTestRunner({
|
|
testSuite: ({ getContainer }) => {
|
|
let container!: MedusaContainer
|
|
|
|
describe("EventBusModule", () => {
|
|
beforeAll(() => {
|
|
container = getContainer()
|
|
})
|
|
|
|
it(`should emit event with the expected shape to be received by the subscribers`, async () => {
|
|
const eventBus = container.resolve(Modules.EVENT_BUS)
|
|
const eventName = "test-event-payload"
|
|
|
|
await eventBus.emit(
|
|
composeMessage(eventName, {
|
|
data: {
|
|
test: "foo",
|
|
},
|
|
object: "object",
|
|
source: "source",
|
|
action: "action",
|
|
})
|
|
)
|
|
|
|
expect(testEventPayloadHandlerMock).toHaveBeenCalled()
|
|
expect(
|
|
testEventPayloadHandlerMock.mock.calls[0][0].pluginOptions
|
|
).toEqual(expect.any(Object))
|
|
expect(testEventPayloadHandlerMock.mock.calls[0][0].event).toEqual({
|
|
name: eventName,
|
|
data: {
|
|
test: "foo",
|
|
},
|
|
metadata: {
|
|
object: "object",
|
|
source: "source",
|
|
action: "action",
|
|
},
|
|
})
|
|
})
|
|
})
|
|
},
|
|
})
|