Migrating to 1.0.0
This document summarizes some breaking changes that were made during the Flamework 1.0 release.
This document will only detail larger breaking changes, it is still recommended that you read the full release notes before migrating.
If you do not have an existing codebase, please refer to the installation guide.
Core
These are migration steps for @flamework/core
Glob addPaths
has been replaced with addPathsGlob
Previously, you could use globs under the addPaths
function and it'd match all directories that matched the given glob.
You must now use addPathsGlob
which will run the path directly through the glob.
Flamework now matches files by default, and you must specify directory matching in the glob (using a trailing /
).
This means if you used the glob src/*/server
, you must now use src/*/server/
to match only directories.
- Replace
addPaths({ glob: "file" }, "path")
withaddPathsGlob("path")
- Replace
addPaths("path")
oraddPaths({ glob: "directory" }, "path")
withaddPathsGlob("path/")
Networking
These are migration steps for @flamework/networking
Revised networking setup
Flamework no longer specifies configuration in the shared networking file, and you must now configure networking on the server and client individually.
- Replace
GlobalEvents.server
andGlobalEvents.client
withGlobalEvents.createServer({})
andGlobalEvents.createClient({})
respectively. - You must move your config from
shared/networking.ts
toserver/networking.ts
andclient/networking.ts
(or your respective files).
// `createEvent`/`createFunction` no longer accepts configuration.
const GlobalEvents = Networking.createEvent<Server, Client>();
const Events = GlobalEvents.createServer({ /* server config */ })
const Events = GlobalEvents.createClient({ /* client config */ })
Networking failure events are now under GlobalEvents
These were previously exposed under the Networking
namespace, but they are now under the individual GlobalEvents
API.
These updated events also pass an object containing the event information as opposed to multiple arguments. Refer to the documentation for additional information.
- Replace
Networking.registerNetworkHandler("name", callback)
withGlobalEvents.registerHandler("name", callback)
- The handlers now only pass 2 parameters: the player and the specific event's information object
// `createEvent`/`createFunction` no longer accepts configuration.
const GlobalEvents = Networking.createEvent<Server, Client>();
GlobalEvents.registerHandler("onBadRequest", (player) => print(player, "sent a bad request!"));
GlobalEvents.registerHandler("onBadResponse", (player) => print(player, "returned a bad response!"));
Components
These are migration steps for @flamework/components
Component maids were removed
Components no longer include a maid by default.
If you'd like to replace the previous behavior, you can create a new DisposableComponent
and use that for components instead of BaseComponent
.
You can replace maid with the cleanup solution of your choosing.
export class DisposableComponent<A = {}, I extends Instance = Instance> extends BaseComponent<A, I> {
protected maid = new Maid();
override destroy() {
this.maid.Destroy();
// You must still call BaseComponent's destructor!
super.destroy();
}
}
Modding
These are migration steps for the @flamework/core
modding API.
Modding.Generic
and Modding.Caller
can only emit a single type of metadata
These APIs now only generate a single type of metadata (e.g Modding.Generic<T, "guard">
will now compile directly to t.string
instead of an object).
Flamework exposes backwards compatible APIs, but you should consider using the new APIs when possible.
- Replace any existing usages with the backwards compatible
Modding.GenericMany
orModding.CallerMany
APIs.