Fixes: FRMW-2858
This PR merge the modules exported by the plugins with the modules defined within the user config. As a result, all modules get loaded without changing the internals of the loader.
However, you cannot disable the module of a plugin by re-adding it to the `modules` array. That is something we should handle separately.
We've added the breaking change label because of the following fix:
We did broke the ability to completely disable modules in the past pr's, in this pr we re add the ability to disable a module and that this modules does not get loaded at all. ([here](6dd164f783))
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
* feat: Custom line items
* fix tests
* fix migration
* Allow custom items in update line item workflow
* throw if line item doesn't have a price
* minor things
* wip
* fix flows
* fix test
* add default
* add to type
* fix(carts): Fixes cart modifications not accounting for certain price lists (#10493)
*What*
* Fixes#10490
* Expands any available customer_id into its customer_group_ids for cart
updates that add line items.
*Why*
* Cart updates from the storefront were overriding any valid price lists
that were correctly being shown in the storefront's product pages.
*How*
* Adds a new workflow step that expands an optional customer_id into the
customer_group_ids it belongs to.
* Uses this step in the addToCartWorkflow and
updateLineItemInCartWorkflow workflows.
*Testing*
* Using medusa-dev to test on a local backend.
* Adds integration tests for the addToCart and updateLineItemInCart
workflows.
Co-authored-by: Riqwan Thamir <rmthamir@gmail.com>
* chore: update cart workflows to accept new pricing context
* chore: add transfer specs
* chore: fix specs
* chore: modify types + specs
* chore: add data migration + dashboard changes
* chore: fix update line item workflow
* chore: add changeset + unskip spec
---------
Co-authored-by: Sergio Campamá <sergiocampama@gmail.com>
What:
- `Dirent` class from `NodeJS` has different properties in different versions, causing issues in our loaders.
- Util `readDirRecursive` was introduced, avoiding old node versions to break
FIXES: https://github.com/medusajs/medusa/issues/8419
What:
* removes resouces type "shared" or "isolated" from internal modules.
* modules can have an isolated database connection by providing a database config as part of their options on `medusa-config`
CLOSES: FRMW-2593
**Breaking changes**
The `outDir` has been deprecated and wont be used anymore, instead all the path are computed internally following these rules
- if admin is not `disabled` and the `build` command is run without the `--admin-only` flag, then the admin output dir will be `.medusa/server/public/admin` and it will be served from that same location from the medusa instance.
- if admin is not `disabled` and the `build` command is run with the `--admin-only` flag, then the admin output dir will be `.medusa/admin` with the purpose of deploying the admin separately. ⚠️ (expect to receive a warning log)
- if the admin is `disabled` and the `build` command is run with the `--admin-only` flag, then fallback to rule number 2
| admin enabled | medusa build --admin-only | output dir |
|---|---|---|
| true | true | `.medusa/admin` ⚠️ (expect to receive a warning log) |
| true | false | `.medusa/server/public/admin` |
| false | true | `.medusa/admin` |
| false | false | none |
```diff
// medusa-config.ts
{
// ...
admin: {
- outDir: 'some/path'
}
}
```
cc @kasperkristensen @sradevski @olivermrbl
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>
**What**
cleanup and move the feature flag related resources to manage them.
It also include some refactoring around loading and registering the flag as well as not relying on the `glob` package anymore plus some reorganization of the code itself
FIXES FRMW-2625
**What**
- Initiate the framework package (which is just a place to move things around for now)
- move the config loader and related resources as well as the `ConfigModule` type
- Create a ConfigManager singleton which prepare and store the config (later can be stored entirely in the container) and allow for easier test override
- re export the logger from the framework
- replace medusa config loader with the framework one
- `build` run type check on tests as well but `prepublishOnly` will not fail on build if tests are typed broken
FIXES FRMW-2607
FIXES FRMW-2609
FIXES FRMW-2614
FIXES FRMW-2618
