Closed RomainLanz closed 3 months ago
I would suggest trying something like this :
// utils.ts
export function isModuleInstalled(moduleName: string) {
const require = createRequire(import.meta.url)
try {
require.resolve(moduleName)
return true
} catch (error) {
return false
}
}
// index.ts of @adonisjs/auth
let withAuthFindder
if (isModuleInstalled('@adonisjs/lucid')) {
withAuthFinder = await import('./with_auth_finder')
}
export { withAuthFinder }
this should work fine
Can't use import.meta.resolve
?
Should we implement the suggestion shared by @Julien-R44 or have a breaking change release that moves the import to a sub-module?
import { withAuthFinder } from '@adonisjs/auth/mixins'
Should we implement the suggestion shared by @Julien-R44 or have a breaking change release that moves the import to a sub-module?
import { withAuthFinder } from '@adonisjs/auth/mixins'
It feels better to have the withAuthFinder
method in its own sub-module, but I believe we can implement @Julien-R44's suggestion to avoid a breaking change.
However, we keep in mind that this needs to be done in the next major release.
i agree a breaking change just for that would be a bit annoying
I would say :
withAuthFinder
from the mixins
submodule right nowwithAuthFinder
exported from the root module with deprecated
tag so people can migrate in peace
Ohh yeah, deprecation + new export will be the best
@RomainLanz Can you do a PR for it and at the same time update docs to use new import path, so that atleast new apps are using the submodule.
In case anyone comes here later, assuming you are using lucid, to adopt this change simply update
import { withAuthFinder } from '@adonisjs/auth'
to
import { withAuthFinder } from '@adonisjs/auth/mixins/lucid'
Hey there! 👋🏻
The
@adonisj/auth
module strictly depends on@adonisjs/lucid
since we added thewithAuthFinder
mixins.The mixin imports a Lucid decorator at its root:
Since we are exporting the mixin from the root of the package, we strictly depend on it and cannot use the Auth module without installing Lucid.
We must find a way to remove this hard dependency without adding any breaking change to the current API.